デジタル料金納付注記の正当性証明の方法およびその実行のための装置
本発明は、料金納付キーを用いて生成され郵便物に添付される郵便証印の信頼性の証明のための方法に関し、郵便証印に含まれる暗号情報を解読して郵便証印の信頼性の証明に用いる。
本発明による方法は、データキー（ＫＤ）が生成され中央支払保証システムから局所支払保証システムへと伝達されることを特徴とする。
本発明による方法は、データキー（ＫＤ）が生成され中央支払保証システムから局所支払保証システムへと伝達されることを特徴とする。
【発明の詳細な説明】
【背景技術】
【０００１】
デジタル郵便証印を有する郵便物の作成手続きは公知である。
郵便物の差出人がデジタル郵便証印をより容易に作成できるように、例えば、ドイチェポストＡＧの用いる料金納付システムによって、顧客のシステムにおいて郵便証印を作成し、望ましいインターフェースを介してそれをプリンターから出力することが考えられる。
この形式のための方法の１つが、ドイツ予備出願公開ＤＥ １００ ２０ ４０２ Ａ１において開示されている。
【０００２】
この方法の不正な使用を避けるために、デジタル郵便証印は、例えば該郵便証印の作成を制御する顧客のシステムの識別に関する暗号情報を含むものとする。
【０００３】
この発明は、郵便証印の信頼性を素早く確実に証明可能とする方法の考案、という目的に基づいている。特に、該方法は大規模な、とりわけメールセンターまたは貨物センターでの証明手続きにおける利用に適していることが好ましい。
【発明の開示】
【０００４】
本発明によってこの目的は、信頼性証明の方法を、データキーを生成し中央データベース（ＺｉｎＳセントラルシステム）から局所支払保証システム（ＺｉｎＳローカル）へと伝達することによって達成される。これは生成された料金納付キーと郵便物に添付された郵便証印を用いてなされ、郵便証印に含まれる暗号情報を解読して該郵便証印の信頼性の証明に用いる。
【０００５】
該方法の安全性を高めるためには、局所支払保証システムがデータキーを受け入れ、受け入れの結果を中央データベース（ＺｉｎＳセントラルシステム）に伝達することが有利である。
【０００６】
この方法の特に好ましい実施形態においては、受け入れの結果はデータレコードとして伝達される。
該データレコードはキーを含むことが好ましい。該キーには様々な属性を持たせることができる。特に、対称キーまたは非対称キーとすることができる。意図して使用することによって、該キーは情報の解読および／または暗号化に用いることができる。その性質によって、該キーによって情報を伝達することもできる。例えば、キーには料金納付キー、そのキーの生成、および／またはその終了日付に関する情報を持たせることができる。
【０００７】
キーの均質な置換を保証するためには、中央データベース（ＺｉｎＳセントラルシステム）において受け入れの結果を確認し、それを値転送センター（郵便料金ポイント）に伝達することが有利である。
【０００８】
前記方法のこの実施形態によって、受け入れの結果の機能として、値転送センターでのさらなる処理手順の実行が可能となる。
【０００９】
この結果は様々な方法で確認される。しかし、結果をキーの解読によって確認することが特に有利である。
【００１０】
前記方法の好ましい実施形態は、まずデータキーをほぼ全ての局所支払保証システム（ＺｉｎＳローカル）へと受け入れ、値転送センターにおいて該データキーを新たな料金納付キーとして放出し、続いて新たな郵便証印の作成に用いることを特徴とする。
前記方法のこの実施形態によって、支払保証システムで先に行われたキーの置換の機能としての値転送センターでのキーの置換が可能となる。この方法によって、既に局所支払保証システムに存在していた新たなキーを用いてのみ郵便証印が作成されることが保証される。これによって、局所支払保証システムにより個々の生成された郵便証印の信頼性を証明可能であることが保証される。
【００１１】
前記方法の、この特に好ましい実施形態は、局所支払保証システムでのキーの置換の機能としての値転送センターでのキーの置換の制御を伴うが、これを少なくともいくつかの本発明に関する他の処理手順と組み合わせることが特に有利である。
特に、複数の特徴の組み合わせによって、キーの置換を素早く確実に行われることと、個々のキーの置換の実行が証明されることとが保証される。
【００１２】
キーの置換が行われる際に、新たなデータキーを値転送センター（郵便料金ポイント）から中央支払保証システムへと伝達することが有利である。
ここで、値転送センターにおいてデータキーを移送キー（ＫＴ）を用いて暗号化することが特に有利である。
ここで、移送キーをマスター移送キー（ＫＴＭ）を用いて暗号化することが実際的である。
【００１３】
データキーは値転送センター内で生成することが好ましい。これにはデータキーが値転送センターへの移送中に不正に変化されることを防止できるという利点がある。
データの安全性をさらに高めるためには、データキーをキー識別情報とともに提供することが有利である。
キー識別情報もまた暗号化した形式で伝達することが有利である。
【００１４】
個々の暗号化および／または解読の手順において正当なデータキーが用いられていることを保証するためには、データキーを生成カウンターとともに提供し、さらに／あるいは生成カウンターとともに伝達することが有利である。
【００１５】
無効なキーの使用を避けるためには、料金納付キーを先のデータキーの終了日とともに提供し、さらに／あるいは終了日とともに伝達することも有利である。
【００１６】
前述のデータキーは１つ以上の部分的な証明や、郵便証印の作成、および／または郵便証印に含まれる情報の解読に用いることができる。
【００１７】
郵便証印に含まれる暗号情報の解読を部分的な証明に含むことが特に有利である。
【００１８】
暗号情報の解読を証明手順に統合することで、郵便証印の信頼性を確認し、証明をリアルタイムで行うことが可能となる。
【００１９】
さらに、部分的な証明の１つが暗号情報の作成の日付と現在の日付との比較を含むことが有利である。郵便証印の作成の日付の、特に暗号化された形式での統合がデータの安全性を高める。それは、郵便証印の作成の日付と現在の日付との比較によって郵便証印の二重使用を防止できるからである。
【００２０】
証明速度のさらなる向上のためには、読み取りユニットと証明ユニットとが同期プロトコルによって情報を交換することが有利である。
本発明の別の同様な実施形態においては、読み取りユニットと証明ユニットとは非同期プロトコルによって互いに通信する。
【００２１】
ここで、読み取りユニットから証明ユニットへとデータ電文を送ることが特に有利である。
該データ電文は郵便証印の内容を含むことが好ましい。
【００２２】
本発明のさらなる利点、特徴および実際的な改良は、従属する請求項と図面に基づいて説明される以下の好ましい実施形態の提示とから見つけることができる。
【００２３】
図１は本発明によるキーの配布の特に好ましい実施例である。
図２は本発明によるキー配布システムの適用例である。
図３は 中央支払保証システム（ＺｉｎＳセントラルシステム）と値転送センター（郵便料金ポイント）との間のインターフェースの概略図である。
図４はデータキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための手順である。
図５は付随する暗号を含む、中央支払保証システム（ＺｉｎＳセントラルシステム）から局所支払保証システムへのキーの配布の概略図である。
図６はＤＬＬインターフェースの接続である。
図７はコンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図である。
【発明を実施するための最良の形態】
【００２４】
以下において本発明を、ＰＣ料金納付システムに関して説明する。ここで、支払保証のための手順は、郵便証印の作成に用いられるシステムから独立している。
個別の証明ステーション、特にメールセンターにおける前記の分散証明が特に好ましいが、集中証明も同様に可能である。
【００２５】
本発明の特に好ましい実施例においては、前記の個別の証明ステーションは局所支払保証システムとし、これらは好ましくはデータ接続によって中央支払保証システムに接続される。
前記の特に好ましい実施例において、中央支払保証システムはまた値転送センターにも接続される。
値転送センターの特に好ましい実施例を、以下において郵便料金ポイントと呼ぶ。中央支払保証システムの有利な実施例を、以下においてＺｉｎＳセントラルと呼ぶ。
【００２６】
値転送センターと支払保証システムとの間に実装される技術的インターフェースは、暗号キーの置換からなる。
【００２７】
転送センターと支払保証システムとの間で置換されるキーは、作成された郵便証印が偽造ではないことを保証する。これは、郵便証印を形成する二次元バーコードの一部を該キーによって暗号化することで達成される。能力による理由のために、選択されたキーは対称キーなので、転送センターから支払保証システムへと伝達される必要があり、そこから個別のメールセンターに配布される。
【００２８】
キーの高信頼保存は特別な暗号カードを用いることによって保証される。本発明は、これらのキーをこの特別なハードウェアを用いて管理する複数の適用例を包含する。これらのキーの生成から送出、配布、分散システムへの受け入れまでの全体の寿命は、プロセスパラメータの最適化のために用いられる。
【００２９】
キー配布のための特に好ましいシーケンスを図１に示す。
図１に、値転送センターと中央支払保証システムとの間での特に好ましいキー配布を示す。
郵便証印の作成に用いられる料金納付キーの置換のための最初の手順１において、まず新たな料金納付キーが生成される。
【００３０】
前記のキーは郵便証印の生成のための異なるやり方に用いることができるので、ここで料金納付キーという語を限定した意味で理解することはできない。
例えば、料金納付キーを直接郵便証印の作成のために用いることができる。
【００３１】
しかし、改ざんに対して特に安全性の高いシステムによって、多重に暗号化したデータ内容を有する郵便証印を作成することも、可能であり特に有利である。ここで該データ内容は好ましくは複数の操作によって形成され、１つ以上の場所で操作の結果を料金納付キーとともに郵便証印に組み込む。
例えば、ドイツ予備出願公開ＤＥ １００ ２０ ４０２ Ａ１に開示される形式の暗号文字列は料金納付キーに組み込まれる。
【００３２】
郵便証印の不正な作成に対し防御をさらに向上するために、料金納付キーのイベント特有の置換を行う。
提示された例において、料金納付キーは所定の間隔をあけて、例えば事前に定義できる時間間隔の満了の後で、新たに生成される。
【００３３】
しかし、料金納付キーの新たな生成を他のパラメータの機能として、例えば郵便物の課金額および／あるいは支払済みの郵便物に基づいて行うことも可能である。
【００３４】
原則の問題として、新たな料金納付キーの新たな生成はどこでも行える。しかし、データの安全性を高めるためには、新たな料金納付キーの伝達の労力を最小限とし、キーを値転送センター内で、あるいは値転送センターの領域内で生成することが有利である。
【００３５】
不正に対する方法の高レベルでの防御を保証するためには、郵便証印に含まれる情報を局所支払保証システムの領域内、例えばメールセンターまたは貨物センター内において料金納付キーに基づいて解読することが有利である。
これを保証するために、料金納付キーを値転送センターから中央支払保証システムへと伝達する。この伝達は自動化することが好ましい。
【００３６】
置換は支払保証システムのサーバー（ＺｉｎＳセントラルサーバー）を介して実施することが好ましい。値転送センター（郵便料金ポイント）を設定する必要はない。サーバーは値転送センター（ＺｉｎＳローカルシステム）とそれに属する暗号システムを認識する必要がないので、ＺｉｎＳセントラルサーバーのみが前記サーバーとして重要である。
【００３７】
好ましい対称型の料金納付キーの新たな生成の後で、後者は中央支払保証システムへと安全に伝達され（図１の手順２）、そこから局所支払保証システム内の暗号システムへと配布される（図１の手順３）。局所支払保証システム内から受け入れ操作の結果が返送され（図１の手順４）、キーの受け入れの成功が確認される。結果を中央システムでコンパイルし、確認し値転送センター（郵便料金ポイント）へと伝達する（図１の手順５）。
【００３８】
キーの全ての局所支払保証システム内の暗号システムへの受け入れが成功すると、値転送センター（郵便料金ポイント）において放出され、続いて新たな郵便料金額の生成に用いられる（図１の手順６）。
【００３９】
好ましい対称型の料金納付キーは、料金納付キーを用いて作成される郵便証印の偽造への安全性において不可欠な部分であり、該郵便証印は例えば二次元バーコードの形式とする。したがって、これらのキーの置換は強力な暗号法によって安全を確保する必要がある。これを保証するためには、以下の点を支持することが特に重要である。
・内容の機密性：伝達の間に、第三者が伝達されるキーを読み出すことが可能であってはならない。さらに、キーが安全に保存され、第三者による読み出しが不可能であることも保証されなければならない。後者の機能性はウェブセントリー（ＷｅｂＳｅｎｔｒｙ）の暗号カードによって保証される。
・内容の保全性：第三者がキーの一部を偽造することが可能であってはならない。
・認証：双方の通信パートナーは差出人／受取人の認証が正しいことを確認しなければならない。受取人の見地からは、これはキーが郵便料金ポイントにおいて生成されたということを意味する。差出人の見地からは、正当なＺｉｎＳローカル暗号システムのみがキーを受信できることが保証されなければならない。
【００４０】
提示された対称型の方法において、双方の通信パートナーは同一のキーＫＴを持つ。値転送センター（郵便料金ポイント）はキーＫＴを用いて、伝達されるデータキーＫＤを暗号化し、それからデータキーＫＤを支払保証システム（ＺｉｎＳセントラルシステム）のサーバーへと転送する。
【００４１】
それからこのキーをさらに中央支払保証システムから局所支払保証システムのＺｉｎＳローカル暗号システムへと移送する。これらのシステムもキーＫＴにアクセスし、それによってキーＫＤを再び解読できる。キーＫＤを移送の間に安全に防御するためにキーＫＴを用いるので、キーＫＴも以下において移送キーと呼ぶ。
【００４２】
全ての局所支払保証システムが同じデータを受信するので、個々の局所暗号サーバーと値転送センター（郵便料金ポイント）との間で別々の移送キーＫＴを定義する必要がない。しかし、安全性の理由から、このキーＫＴはデータキーＫＤのように一定の間隔で更新するべきである。しかし、キーＫＤではあまり多くのテキストを暗号化しないので、交換の間隔は長くすることができる。１年または２年の交換間隔が、ここでは特に有利である。
【００４３】
この方法の不可欠な構成要素は移送キーＫＴの置換であり、これは安全性の理由から、データキーＫＤの置換と同じチャンネルで行うべきではない。この置換は手動では行わない。この手続きは複数の局所支払保証システムについて一定間隔で行わなければならないので、移送キーの置換も自動化できるように、ここで別の手法を提供しなければならない。
【００４４】
この目的のために、ＡＮＳＩ規格Ｘ９．１７（金融サービスのための対称手法に基づいたキー管理）において、マスター移送キー（以下、ＫＴＭと呼称）と呼ばれる別のキーレベルが定義されている。このキーは特別な安全性警戒の元で暗号カードにインストールしなければならず、また拡大した間隔において置換しなければならない。ここで、全てのシステムに同じＫＴＭがインストールされる。それからこのキーで移送キーＫＴを暗号化し、その後キーＫＴを同じチャンネルによって自動化された様式で配布し、受け入れを行う。該配布はデータキーの配布と同様に行われる。個別のシステムまたはその暗号カードの初期化については以下の節で詳述する。
【００４５】
メッセージの保全性と差出人（郵便料金ポイント）の認証を保証するために、個別のキーメッセージにマトリクスコード（ＭＡＣ）が形成される。ＭＡＣの生成のために、ＫＴＭと同様に暗号カードの初期化の間に受け入れられる署名キーＫＳが必要となる。データキーメッセージの署名は、その後でこのキーＫＳによってなされる。ドイチェポストのイントラネット内での伝達の間におけるメッセージの機密性は、強い暗号手法を用いることでこのように確保される。メッセージの暗号化と解読の特に好ましい手法はトリプルＤＥＳ（キー長１６８ビット）である。ハッシュ値はＳＨＡ−１アルゴリズムによって計算することが好ましい。
【００４６】
郵便料金ポイントと支払保証システムの暗号システムに存在する正当性の様々な周期を、データキーの配布と保存のために考慮しなければならない。最大２つのキーＫＤが所定の時間において郵便料金ポイントで利用可能でなければならない。つまり、１つのキーは現在正当であり、新たに生成された郵便料金額を伴うもう１つのキーは暗号化される（ＫＤｎｅｗ）。
【００４７】
該キー（ＫＤｎｅｗ）による既存のキーの操作の‘置換’モードにおいて、新たなキーが支払保証システムの暗号システムに伝達される。このキーを全ての局所支払保証システムの暗号システムに受け入れ成功してから、ＺｉｎＳセントラルシステムの放出メッセージが生成され、この時点において、ＫＤｎｅｗが郵便料金ポイントの新たな郵便料金額の暗号化に用いられる。この時点において、古いＫＤは郵便料金ポイントから消去すべきであり、またこれ以上新たな郵便料金額の生成に用いられるべきではない。
【００４８】
局所支払保証システムの暗号システムでは状況は異なる。ダウンロードされた郵便料金額は事前に定義できる時間の周期、例えば３ヶ月にわたって郵便証印の作成に使用でき、複数のキーＫＤが郵便証印の証明に利用可能でなければならない。
【００４９】
さらに、キーの配布の際には、暗号システムに受け入れられず郵便料金ポイントにおいて有効化できなかったキーに何があったのかも考慮すべきである。これらのキーを他の暗号システムに受け入れさせることが可能であり、原則の問題として、さらなる証明の間についても考慮すべきである。
【００５０】
ここで、キーの明瞭な更新と可能な最も単純なシステムのメンテナンスを許容する一様な状態に達するためには、以下のキー配布の手法の実行方法の形式が特に好ましい。
（ａ）データキーは暗号化された形式で、確定したキーＩＤ（キー位相表示）、不確定な生成カウンター、および正当先行データキーとともに伝達される。
（ｂ）値転送センター（郵便料金ポイント）からのデータキーの個々の伝達は、中央支払保証システムで確認メッセージによって確認されるべきである。
（ｃ）確認が正だった場合は、全ての局所支払保証システムへのデータキーの受け入れは成功していて、顧客はキーを利用してＰＣ料金納付を行うことができる。
この場合、生成カウンターは続くキーの伝達のたびに増加する。
（ｄ）確認が負だった場合は、全ての局所支払保証システムへのデータキーの受け入れは成功しておらず、値転送センターは顧客のシステムに郵便証印を作成させるべきではない。でなければ正当な郵便物が多量に転用される危険があるためである。
この場合、生成カウンターは続くキーの伝達のたびに増加しない。すなわち、先の伝達の値のままとなる。
（ｅ）確認がない場合は、その間、値転送センター（郵便料金ポイント）はこれ以上の中央支払保証システム（ＺｉｎＳセントラル）へのキー伝達が不可能となる。（このような試行は当然、支払保証システムによって却下されるが、値転送センター内で阻止すべきである）
（ｆ）延長された時間周期にわたって支払保証システムによる確認がない場合（タイムアウト超過）、値転送センター（郵便料金ポイント）はその直接あるいは間接のユーザーインターフェースによって警報を出すことができる。
（ｇ）暗号カードがデータキーを受信したらすぐに、最前の伝達としての同じ生成カウンター値を持つデータキー全てを消去する。これによって、エラーによる伝達が多数の場合、かつて暗号カードへの読み込みに成功したキーのみが消去される。トランザクションの安全なキー伝達が許容される。
（ｈ）局所支払保証システムの暗号カードにおいて、ルーチンが繰り返し、好ましくは定期的に、特には日毎に呼び出され、それは既に必要でなくなったデータキーを消去する。続くデータキーに関してＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性に保存された終了日付が現在のシステムデータより小さい際に、データキーは（（ｇ）や他の有利な実施例において）消去される。
（ｉ）先のキーの終了日付になると、（できるだけ短い）猶予期間が計画されるべきである。それは、局所支払保証システムの領域で確認されると、失効した郵便料金額とともに作成された郵便証印が、その正当性が終了した後でまださらに２日間正当だと認識されるためである。さらに、新たなデータキーの生成と放出のタイムラグも考慮しなければならない。
【００５１】
図２において現在のキーの管理の適用領域とその支払保証の領域における利用の概観が示される。さらに、適用の好ましい領域が提示される。
以下において適用例を詳述する。
【００５２】
続いて、前述のキー管理手法の詳細を提示する。
前述の適用は、暗号カードを用いる例によって提示する。
【００５３】
まず、値転送センターの領域において暗号カードを初期化する方法を提示する。
・製造業者の範囲においては、カードのインストールと設定、カードのファームウェアのアップロードはまだなされていない。ファームウェアの機能性は埋め込まれたコード（著作権のあるソフトウェアルーチン）によって拡張される。安全性の理由から、ＰＫＣＳ＃１１（公開鍵暗号基準）によるキールーチン（生成、消去等）はユーザーによって阻止されるべきである。これにより、カードにおいてより高いキーの安全性が保証される。
・（複数の暗号カードを有する）クラスターの定義。
・局所マスターキーＬＭＫの生成と保存。ＬＭＫは３つ以上の成分に配布されるべきであり、成分の２つは暗号サーバーカードの再形成または初期化に特に有利である。個々の成分はスマートカードにＰＩＮ防御によって書き込まれることが好ましく、そして安全性管理者はスマートカードを受け取る。なお、バックアップのスマートカードも作成すべきである。その後、ＬＭＫを前記のマスター移送キーＫＴＭとして用いる。
・ユーザー管理：デフォルトの安全性管理者の消去と、（スマートカードに基づく）必要な認証規則を含む安全性管理者の定義。
・初期の署名キーＫＳの生成、ＫＴＭによる暗号化（ラップ）およびファイルとしての保存。このファイルのディスケットへの後のコピーは可能とすべきである（ファイル／ディスケットへのアクセスは安全性管理者にのみ可能とすべきである）。
・最初の移送キーＫＴの生成、付随するキーメッセージの創作、およびメッセージのファイルへの保存とその後での該ファイルのディスケットへのコピー（アクセスは安全性管理者にのみ可能とすべきである）。
【００５４】
［移送マスターキーの生成］
新たな移送マスターキー（ＫＴＭ）は以下に述べる様式で生成することが望ましい。付随する確認カードの局所マスターキー（ＬＭＫ）をＫＴＭとして用いる。安全性の理由から、ＬＭＫは３つ以上の成分に分割されるべきであり、成分の２つ以上は再受け入れに必要である。
【００５５】
個別の成分をスマートカードに保存し、個々の安全性管理者はスマートカードを受け取り個々のＰＩＮによりその安全性を確保する。ＰＩＮの機密を維持しスマートカードを安全な場所に保存することで、権限のない者がそれらにアクセス可能となることを防ぐ。
【００５６】
移送マスターキーの実装のために、２つ以上のＬＭＫ成分（２つの異なる認可カードに関する）が存在することが好ましく、これによって二重制御原則の自動的な実装が実行される。
【００５７】
ＫＴＭはトリプルＤＥＳキーでなければならない。キーのＩＤ属性は型式識別および確定した数からなる。
型式識別：ＫＴ
確定した数：０１から９９
長さ：固定４バイトがＣＫ＿ＣＨＡＲ［ ］として保管される。
【００５８】
原則の問題として、認可された者のみがキーを置換可能であることを保証するために、様々な安全性機構が適している。しかし、以下で述べる署名キーを用いる実施例は、改竄操作に対する特に高い安全性をもたらすので、特に有利である。
【００５９】
署名キーはキーメッセージの保全性を保証する。これはまた、キーメッセージの差出人が郵便料金ポイントであるかどうかを確認するのにも利用できる。署名キーの生成は、スマートカードで登録された安全性管理者にのみ可能とすべきである。これは、ＴＲＵＥに設定された‘感受性’とＦＡＬＳＥに設定された‘抽出’の安全性属性を有し、キー平文がカード外部で発見されることを防ぐＴＤＥＳキーであるべきである。キーのＩＤ属性は型式識別および確定した数からなる。
型式識別：ＫＳ
確定した数：０１から９９
長さ：固定４バイトがＣＫ＿ＣＨＡＲ［ ］としてファイルされる。
【００６０】
キーは送出のためにＫＴＭでラップする必要があり、それからディスケット上にファイルとして保存される。ディスケットは安全な場所に置かねばならず、暗号カードの初期化に用いる。キーファイルの保全性は、好ましくはラップに用いるカードに保存される、処理ルーチンによって保証される。
【００６１】
移送キーＫＳの好ましい属性は以下の表に編集される。
【００６２】
【表１】
【００６３】
ＬＡＢＥＬ属性の乱数は暗号サーバーカードへの受け入れ成功の確認に用いられる。ハッシュ値（例えばＳＨＡ−１による）はこの乱数のために形成され、受け入れ成功の確認と移送キーの放出のために用いられる。
【００６４】
ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲとしてファイルされる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００６５】
署名キーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化され、ＬＭＫのようにサイト上のハードウェアにアップロードされる。
【００６６】
移送キーの生成について以下で述べる。
この適用例においては、付随するキーメッセージを含む移送キーが生成される。
移送キーおよび／または付随するキーメッセージは安全性管理者によってのみ初期化可能なようにキー生成モジュールを設定することが好ましい。置換間隔は１年または２年とすべきである。
【００６７】
次に、移送キーは、以下の属性設定を備えるＴＤＥＳキーである。
【００６８】
【表２】
【００６９】
ＬＡＢＥＬ属性の乱数は暗号サーバーカードへの受け入れ成功の確認に用いられる。ハッシュ値（例えばＳＨＡ−１による）はこの乱数のために形成され、受け入れ成功の確認と移送キーの放出のために用いられる。
【００７０】
ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲとしてファイルされる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００７１】
移送キーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化され、値転送センターから中央支払保証システムへの伝達のために以下の構造を持つメッセージが形成される。
【００７２】
【表３】
【００７３】
さらなる配布に続いて、この移送キーメッセージはＺｉｎＳセントラルサーバーへと転送される。インターフェースはセッションビーンによって実現され、このサービスは指定のサービス（Ｊａｖａ Ｎａｍｉｎｇ ａｎｄ Ｄｉｒｅｃｔｏｒｙ Ｉｎｔｅｒｆａｃｅ−ＪＮＤＩ）によって調べられる。移送の手法は前記のデータブロックを要求すべきである。
【００７４】
さらに、メッセージを郵便料金ポイントにファイルとして保存し、安全性管理者はこれを後で、安全な場所に保存される１つ以上のディスケットに保存することができる。ディスケットはそれから暗号サーバーカードの初期化に用いられる。
【００７５】
移送キーの放出の好ましい実施例を以下に説明する。
値転送センターは移送キーＫＴを放出可能に設定される。移送キーＫＴの放出のために、全ての局所支払保証システム（ＺｉｎＳ暗号システム）への配布と受け入れが成功した移送キーを中央値転送センターから放出可能なインターフェースがある。放出によってのみ、付随する移送キーが続いてデータキー（ＫＤ）の暗号化に用いられる。
【００７６】
前記インターフェースはセッションビーンとして実現される。このサービスは指定のサービスによって調べられる。
放出手続きのデータ構造は以下のパラメータを有することが好ましい。
【００７７】
【表４】
【００７８】
ＰＰキー管理システムに対する支払保証システムのキー割り当てシステム（ＺｉｎＳキー管理システム）の認証はパラメータ２で行われる。これはＳＨＡ−１の手法を用いて移送キーのＬＡＢＥＬ属性から形成されるハッシュ値である。ＬＡＢＥＬ属性は移送キーの生成の際に乱数で埋められる。移送キーとその全ての属性は伝達の間に暗号化されるので、ＺｉｎＳ暗号サーバーのみが正しいハッシュ値を計算できる。
【００７９】
伝達されたハッシュ値がＬＡＢＥＬ属性のために計算されたＫＴのハッシュ値と同一の場合、該ハッシュ値は郵便料金ポイントウェブセントリーモジュールに位置され、伝達された処理ステータスが真の場合、移送キーは有効化される。これは、続いてデータキーメッセージが移送キーを用いて暗号化されることを意味する。
【００８０】
処理が誤っている（伝達されたステータスが偽である）場合には、この適用例の変形が存在する。この場合、このキー生成とキー配布のためのステータスがプロトコル処理され、付随する移送キーはこれによって消去される。
【００８１】
新たなデータキーの生成の好ましい例を以下に示す。
この適用例においては、付随するキーメッセージを含むデータキーが生成される。キー割り当てシステムは、この動作が安全性管理者によってのみ初期化可能なように設定される。これは３ヶ月毎に行われるべきである。中央支払保証システム（ＺｉｎＳセントラルシステム）からフィードバック（放出またはエラー）が受信されておらず、データキーＫＤが流通している場合、フィードバックが受信されるまで新たなＫＤの生成は阻止される。
【００８２】
データキー（ＫＤ）は特定のマトリクスコード内容の暗号化を行い、また支払いが郵便サービス提供者になされていない場合は正当な郵便証印を作成できないことを保証する。このデータキーによってＺｉｎＳ暗号サーバーにおいてデジタル郵便証印が証明される。データキーは、ＰＫＣＳ＃１１機能Ｃ＿ＧｅｎｅｒａｔｅＫｅｙを用いて生成され以下の属性を持つＴＤＥＳキーと同様である。
【００８３】
【表５】
【００８４】
ＣＫＡ＿ＩＤ属性の値と生成カウンターはシステムに規定される。ＣＫＳ＿ＩＤは上方へ１ずつカウントされるが、生成カウンターはキーの放出が成功したときのみ増加する。ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲ ［ ］として埋められる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００８５】
ＬＡＢＥＬ属性の乱数によって暗号サーバーカードへの受け入れの成功が確認される。この乱数のためにハッシュ値が（ＳＨＡ−１によって）形成され、移送キーの受け入れの成功の確認と放出に用いられる。
【００８６】
データキーの置換のためのメッセージの生成はいくらか複雑で、以下のシーケンスを含む。
【００８７】
１． データキーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化される。これには、キーの全ての属性（特にＣＫＡ＿ＥＸＴＲＡＣＴＡＢＬＥ＝ｆａｌｓｅ）が同時に暗号化され、解読の際に正しく再設定されるという利点がある。この暗号化されたバイトシーケンスを用いて、以下の構造を持つ仮のメッセージが形成される。
【００８８】
【表６】
【００８９】
２． 次に、仮のメッセージは有効な移送キーＫＴによって、ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構を用いて暗号化される（初期化ベクターはゼロで埋める）。
【００９０】
３． 配布されるメッセージを形成し、それは以下の構造を有するものとする。
【００９１】
【表７】
【００９２】
４． その後、データキーメッセージをＺｉｎＳセントラルサーバーへのさらなる配布のために転送する。さらに、安全性管理者によって１つ以上のディスケットに保存し、それを安全な場所に保管して、新たなＺｉｎＳ暗号カードの初期化に使用できるようにする。
【００９３】
メッセージ内容の二重暗号化の利点は、暗号化の少ないテキストはインターネット経由でＫＴＭに伝達しなければならず、したがってこのキーの暗号解析がはるかに困難になる、ということである。
【００９４】
データキーＫＤの放出のために、インターフェースとプロトコル機構を設け、データキーの放出をプロトコル処理する。データキーの局所支払保証システムへの配布と受け入れの成功の後にのみデータキーを放出するように中央支払保証システムを設定することが好ましい。この放出によってのみ、付随するデータキーは続いて暗号文字列の暗号化に用いられ、郵便証印に組み込まれ付随キー識別情報ＫｅｙＩＤを郵便料金額の識別情報（ＰｏｓｔａｇｅＩＤ）の中で暗号化する。
【００９５】
インターフェースは中央支払保証システム（ＺｉｎＳセントラル）と局所支払保証システム（ＺｉｎＳローカル）との間のＣＷＭＳ（コンピューター作業管理システム）によって実現される。値転送センター（郵便料金ポイント）ＰＰは適切なビーンから情報を受信する。放出手続きのためのデータ構造は以下の内容を有する。
【００９６】
【表８】
【００９７】
値転送センターＰＰのキー割り当てシステムに対する、支払保証システムのキー割り当てシステムの認証は、パラメータ２によって行われる。これはＳＨＡ−１の手法を用いて移送キーのＬＡＢＥＬ属性から形成されるハッシュ値である。ＬＡＢＥＬ属性は移送キーの生成の際に乱数で埋められる。データキーとその全ての属性は伝達の間に暗号化されるので、支払保証システムの暗号サーバーのみが正しいハッシュ値を計算できる。
【００９８】
伝達されたハッシュ値がＬＡＢＥＬ属性のために計算されたＫＤのハッシュ値と同一の場合、該ハッシュ値は郵便料金ポイントウェブセントリーモジュールに位置され、伝達された処理ステータスが真の場合、移送キーは有効化される。これは、続いて郵便証印／郵便料金額のための暗号文字列がこのデータキーを用いて暗号化されることを意味する。データキーが有効化されると、署名キーの生成カウンターが１つずつ増加する。
【００９９】
処理が誤っている（伝達されたステータスが偽である）場合、この適用例の変形が存在する。この場合、このキー生成とキー配布のためのステータスがプロトコル処理され、付随する移送キーはカードから消去される。この場合、署名キーの生成カウンターが１つずつ増加することはない。
【０１００】
キー割り当てシステムは実行されたキー生成を保存するステータスメモリーを有することが好ましい。実行されたキー生成のついて中央支払保証システム（ＺｉｎＳセントラルシステム）からのフィードバックが受信されていないと、ステータスが開いて表示される。フィードバックと配布が成功すると、有効化されているとしてキーが指定される。エラーの場合は、伝達されたステータスメッセージが表示される。エラーあるいは放出メッセージの不在が延長された場合、エラー調査ルーチンが呼び出される。
【０１０１】
キーをアーカイブすることが有利である。値転送センターの領域における好ましいキーのアーカイブについて以下で説明する。キーの安全性を保証するために、安全性管理者は全てのキー（ＫＴＭを除く）をＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化して返送するアーカイブ機能を開始することができる。これらのキーはデータベースまたは安全ファイルシステム領域に安全に保存されるべきである。
アーカイブの成功の後で、初期正当性日付を６ヶ月以上過ぎて既に有効でない全てのキーが消去される。
【０１０２】
特に値転送センターＰＰの領域において、キーは復旧され、アーカイブされたキーデータは解読され（ラップを解かれ）カードに保存される。ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構が再び用いられる。
キーが解読された後で、既にカードに存在していた同一のキー識別情報ＫｅｙＩＤを有するキーは消去される。
【０１０３】
ウェブセントリーカードの特別な安全性手段と複数のスマートカードへの配布によって、マスター移送キーＫＴＭは漏洩に対し確実に安全性を保証される。
にもかかわらずマスター移送キーの置換がなされる場合は、“暗号カード”（ＰＰ）の初期化を含む適用例と同様に、新たなＫＴＭと新たな署名キー、移送キーおよびデータキーを生成しなければならない。
先のＫＴＭはいわゆる“潜在ＬＭＫ”としてカードに残され、安全性管理者によって適当に消去されなければならない。
【０１０４】
キー割り当てシステムの好ましい適用例を以下で説明する。提示は支払保証システムの全ての領域に適用される。これは特に個別の構成要素が、好ましくは局所支払保証システムまたは中央支払保証システムの領域に実装される場合に有利である。しかし、他の支払保証システムにおける使用も同様に可能である。
【０１０５】
第１の適用例は支払保証システムの領域における暗号カードの初期化である。
暗号カードの初期化のために以下の基本的な設定が用いられ、機能性の大半は管理ツール（ウェブセントリーマネージャー（ＷｅｂＳｅｎｔｒｙＭａｎａｇｅｒ））で管理できる。
・製造業者が既に行っていない範囲での、暗号カードのインストールと設定、カードファームウェアのアップロード。ファームウェアは埋め込まれたコード（著作権のあるソフトウェアルーチン）を有する。（後の機能性はウェブセントリーマネージャーに統合される）
・クラスターの定義づけ（複数の暗号カードを用いる）（ウェブセントリーマネージャー）
・移送マスターキー（ＫＴＭ）の受け入れ、分離適用例を参照（機能性はウェブセントリーマネージャーによって提供される）
・ユーザー管理：デフォルトの安全性管理者の消去と、（スマートカードに基づく）必要な認証規則を含む安全性管理者の定義
あらかじめ定義されたＰＩＮによって認可される、２つの“通常”ユーザーの生成（１つはキー証明のため、もう１つはキー受け入れのため）
ユーザー管理の機能性は同様にウェブセントリーマネージャーによって提供される。
・署名キー（ＫＳ）の受け入れ：分離適用例を参照
・移送キー（ＫＴ）の受け入れ：分離適用例を参照
・随意のデータキー（ＫＤ）の同様な受け入れ：（同様にその適用例を参照）すでに生成された範囲内
【０１０６】
キーは以上で定義したシーケンスにおいて受け入れられなければならない。カードは中央において初期化可能で、完全な暗号システムコンピューターを初期化し、その後送らなければならない。これはウェブセントリーカードがＰＣＩスロットから引き抜かれるとすぐに内部の記憶を消去するからである。
【０１０７】
暗号システムに対しスマートカードリーダーと関連したスマートカードで局所的に識別された２人以上の安全性管理者によってのみ、移送マスターキーを受け入れることが可能であることが好ましい。キーＫＴＭの重要性のために、このキーは二重制御原理を用いてのみカードに受け入れ可能とする。これは適用例“移送マスターキー”において生成された２つ以上のＰＩＮ防御スマートカードが受け入れに必要であることを意味する。
【０１０８】
マスター移送キーＫＴＭは双方のスマートカードを用いてのみ読み込み可能で、キーの使用はＰＩＮ防御されているため、このキーは二重制御原理を用いてのみカードにインストール可能であることが保証される。これによって違法なキーに対し非常に高い水準の防御を提供できる。
【０１０９】
この機能性は管理ツール、ウェブセントリーマネージャーによって提供される。この管理ツールによって、いわゆる局所マスターキー（ＬＭＫ、この構想において述べられたＫＴＭに対応）をスマートカードから読み出し、カードの安全な保存領域に保存することが可能となる。
【０１１０】
ＬＭＫを３つのスマートカードに配布することが特に有利であり、ＬＭＫを暗号ハードウェアに受け入れるために全ての３つの部分が必要である。この場合、マスター移送キーＫＴＭの受け入れのために３人の安全性管理者が必要である。
【０１１１】
署名キーはキーメッセージの保全性を保証する。これはまたキーの受け入れの前に、キーメッセージの送信者が値転送センター（郵便料金ポイント）であるかどうかを決定することにも使用できる。署名キーは異なる方法で生成することが可能で、ここで提示する例は特に有利なものである。付随キーメッセージは管理者によってディスケット上に保存され、この適用例では、初期化される支払保証システムの暗号カードに受け入れられる。
【０１１２】
キーの受け入れのために、ディスケット上に保存されたキーメッセージをマスター移送キーＫＴＭ（ＰＫＣＳ＃１１機能Ｃ＿Ｕｎｗｒａｐ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて解読する。キーメッセージの保全性はこのルーチンによって自動的に確認される。このキーＩＤを持つキーが既に存在している場合は、続いて削除される。
【０１１３】
移送キーメッセージのさらなる移送のために、中央支払保証システムのサーバーにインターフェースが設けられ、これによって配布とそれに続く個別の支払保証システムの暗号システムへの受け入れを初期化することができる。
【０１１４】
インターフェースはＲＭＩサービスによって実現される。このサービスは指定のサービス（ＪＮＤＩ）によって調べられる。配布はＣＷＭＳ（コンピューター作業管理システム）によって、Ｐ／Ｎリストの配布を用いてなされる。
【０１１５】
新たな配布ジョブが創作されると、キーメッセージは全ての現在登録されている暗号システムに転送され、個々の場合にプロトコルの入力が書き込まれる。暗号システムの管理は支払保証システムの適用例によってなされる。
【０１１６】
新たなキーメッセージの受信は個別の暗合システムにおいて受け入れ制御装置によって一定の間隔でなされる（配布機構の機能として）。新たなメッセージが受信されると、適用例“移送キーの受け入れ”が自動的に実行される。この動作の戻り値を確認する。負のフィードバックを受信した場合は、受け入れの試行を３回まで繰り返す。
【０１１７】
３回の試行の後でまだ受け入れが不可能な場合は、失敗に関するプロトコルメッセージをＺｉｎＳセントラルシステムに送信する（再び移転機構の機能として）。受け入れが成功した場合は、正のプロトコルメッセージが発行される。
プロトコルメッセージは適用例“プロトコルキー処理”によって中央で処理される。移送キーの放出も同様に開始される。
【０１１８】
移送キーの受け入れはサイト上の暗号システムを初期化する安全性管理者によって実行されるか、あるいはこの受け入れは受け入れ制御装置が新たな移送キーメッセージを受信した際に受け入れ制御装置によって自動的に開始されるものとする。キーは以下の処理手順によって受け入れられることが好ましい。
【０１１９】
１． カードへの登録はキー受け入れユーザーに属するＩＤとＰＩＮによってなされる。
【０１２０】
２． ハッシュ値はＳＨＡ−１手法を用いて移送キーのフィールド１から５へと形成される。
【０１２１】
３． 署名キーがフィールド４に表示されるキーＩＤを有していることを確認する。
【０１２２】
４． このキーは上記２で形成されたハッシュ値の暗号化に用いられ（ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）、フィールド６と比較される。これらの２つの値が合致すると、保全性が保証され、メッセージがＰＣ料金納付システムによって創作されたことが保証される。
【０１２３】
５． メッセージのフィールド５の内容はＫＴＭ（Ｃ＿ＵｎｗｒａｐＫｅｙ手法、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）によって解読される。結果、適当な移送キーオブジェクトが自動的に生成されカードに保存される。なお、該機構は再び暗黙のうちにキーの保全性と差出人の正確さを確認する。
【０１２４】
６． カードに同一のキーＩＤを持つキーが既に存在する場合、それは消去される。
【０１２５】
７． 新たに受け入れられたキーのＬＡＢＥＬ属性に、ハッシュ値がＳＨＡ−１手法を用いて形成され、これはキーＩＤおよび戻り値としての正のメッセージとともに返送される。
【０１２６】
８． ユーザーのセッションを終了する。
【０１２７】
９． プロトコルメッセージを戻り値から創作し、ＺｉｎＳセントラルシステムに送信する。
【０１２８】
１０． このキーＩＤのために保存されている失敗した試行がリセットされる。
【０１２９】
この適用例の変形は、ルーチンの１つまたはＭＡＣの確認の失敗である。この場合、さらなる処理は打ち切られ、キーＩＤ、エラーコードおよびエラーメッセージを含む戻り値が返送される。キーＩＤについて、保存されている失敗した試行の数が１つずつ増加する。この数が３に達すると、最も新しく転送された戻り値からプロトコルメッセージが創作され、中央支払保証システムに送信される。
【０１３０】
手動での初期化の場合、さらに受け入れの結果が安全性管理者のモニターに表示される。
手順２から７をカードソフトウェアにおいて直接実行することが好ましい（埋め込みコード）。これによって性能および違法に対する安全性が向上する。
【０１３１】
データキーメッセージのさらなる移送のために、中央支払保証システムのサーバーに、局所支払保証システムの個別の暗号システムへのデータキーの配布とそれに続く受け入れのための新たなインターフェースを設ける。
インターフェースはセッションビーンとして実現され、このサービスは指定のサービス（Ｊａｖａ Ｎａｍｉｎｇ ａｎｄ Ｄｉｒｅｃｔｏｒｙ Ｉｎｔｅｒｆａｃｅ−ＪＮＤＩ）によって調べられる。
【０１３２】
配布はＣＷＭＳ（コンピューター作業管理システム）によって、Ｐ／Ｎリストの配布を用いてなされる。
【０１３３】
新たな配布ジョブが創作されると、キーメッセージは全ての現在登録されている暗号システムに転送され、個々の場合にプロトコルの入力が書き込まれる。暗号システムの管理は支払保証システムの適用例によってなされる。値転送センターＰＰにおいてフィードバックが受信されておらず、データキーの配布ジョブが既に循環している場合は、フィードバックの時点までさらなるデータキーの配布ジョブの受容が拒否される。
【０１３４】
新たなキーメッセージの受信は個別の暗合システムにおいて受け入れ制御装置によって一定の間隔でなされる（配布機構の機能として）。新たなメッセージが受信されると、適用例“移送キーの受け入れ”が自動的に実行される。この動作の戻り値を確認する。負のフィードバックを受信した場合は、受け入れの試行を３回まで繰り返す。
【０１３５】
３回の試行の後でまだ受け入れが不可能な場合は、失敗に関するプロトコルメッセージをＺｉｎＳセントラルシステムに送信する（再び移転機構の機能として）。受け入れが成功した場合は、正のプロトコルメッセージが発行される。
プロトコルメッセージは適用例“プロトコルキー処理”によって中央で処理される。移送キーの放出もこの適用例によって開始される。
【０１３６】
移送キーの受け入れはサイト上の暗号システムを初期化する安全性管理者によって実行されるか、あるいはこの受け入れは受け入れ制御装置が新たな移送キーメッセージを受信した際に受け入れ制御装置によって自動的に開始されるものとする。
【０１３７】
データキーメッセージの特徴を考慮して、キーは移送キーの受け入れと同様にして受け入れられる。
【０１３８】
１． カードへの登録はキー受け入れユーザーに属するＩＤとＰＩＮによってなされる。
【０１３９】
２． ハッシュ値はＳＨＡ−１手法を用いて移送キーのフィールド１から７へと形成される。
【０１４０】
３． 署名キーはフィールド５に表示されるキーＩＤを有することを確認される。
【０１４１】
４． このキーは上記２で形成されたハッシュ値の暗号化に用いられ（ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）、フィールド８と比較される。これらの２つの値が合致すると、保全性が保証され、メッセージがＰＣ料金納付システムによって創作されたことが保証される。
【０１４２】
５． 署名キーはフィールド６に表示されるキーＩＤを有することを確認される。
【０１４３】
６． メッセージのフィールド７の内容を、５で確認されたキーによって解読する（Ｃ＿Ｄｅｃｒｙｐｔ手法、ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）。解読結果が仮のメッセージである。
【０１４４】
７． 仮のメッセージのフィールド１の内容はＫＴＭ（Ｃ＿ＵｎｗｒａｐＫｅｙ手法、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）によって解読される。結果、適当な移送キーオブジェクトが自動的に生成されカードに保存される。なお、該機構は再び暗黙のうちにキーの保全性と差出人の正確さを確認する。
【０１４５】
８． カードに同一のキーＩＤを持つキーが既に存在する場合、それは消去される。
【０１４６】
９． 暗号カードの全てのデータキーを読み込み、ＬＡＢＥＬ属性の生成カウンターの値、バイト１が新たに受け入れられたキーと同一かを確認する。同一であれば、これらのキーをカードから除去する。別の局所支払保証システムの暗号システムへの受け入れにおけるエラーによって、これらのキーは値転送センターＰＰにおいて放出されなかった。
【０１４７】
１０． 新たに受け入れられたキーのＬＡＢＥＬ属性のバイト２から６５に、ハッシュ値がＳＨＡ−１手法を用いて形成され、これはキーＩＤおよび戻り値としての正のメッセージとともに返送される。
【０１４８】
１１． 暗号カードによるユーザーのセッションを終了する。
【０１４９】
１２． プロトコルメッセージを戻り値から創作し、ＺｉｎＳセントラルシステムに送信する。
【０１５０】
１３． このキーＩＤのために保存されている失敗した試行がリセットされる。
【０１５１】
この適用例の変形は、ルーチンの１つまたはＭＡＣの確認の失敗である。この場合、さらなる処理は打ち切られ、キーＩＤ、エラーコードおよびエラーメッセージを含む戻り値が返送される。キーＩＤについて、保存されている失敗した試行の数が１つずつ増加する。この数が３に達すると、最も新しく転送された戻り値からプロトコルメッセージが創作され、中央支払保証システム（ＺｉｎＳセントラルシステム）に送信される。
手動での初期化の場合、さらに受け入れの結果が安全性管理者のモニターに表示される。
【０１５２】
手順２から１０をカードソフトウェアにおいて直接実行することが好ましい（埋め込みコード）。これによって性能および違法に対する安全性（特に初期化ベクターＩＶおよびＫＴＭｓにおいて）が向上する。
データキーのクリーンアップは繰り返し、好ましくは定期的に、支払保証システムの可能な限り多くの、好ましくは全ての暗号システムにおいて行われ、これによって既に不要となったデータキーが消去される。
【０１５３】
［データキーのクリーンアップの手続き］
１． カード上の全てのデータキーＫＤを確認し、そのＩＤ（ＣＫＡ＿ＩＤ属性）によって確認順に分類する。
【０１５４】
２． このリストの各キーについて、以下の確認手続きを行う。
Ｉ． キーの後継を決定する（次に大きいＩＤ）。
ＩＩ． 存在する場合、以下を証明する。
（１） 前者の正当性の終了を示す後継のＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性が現在のシステム日付より小さいかどうか。小さい場合は、リストの現在処理されているキーを消去する。
（２） 後継の生成カウンター（ＣＫＡ＿ＬＡＢＥＬ属性のバイト１）が現在処理されているキーの生成カウンターと同一かどうか。同一の場合は、リストの現在処理されているキーを消去する。
【０１５５】
キー処理は中央支払保証システムのサーバー（ＺｉｎＳセントラルサーバー）においてプロトコル処理されることが好ましい。この適用例によってプロトコル処理されるキーは移送キーとデータキーである。
【０１５６】
個々の配布ジョブについて、キーメッセージが送信された有効な暗号システムを示すプロトコルが作成される。個々のシステムと配布ジョブについて、ステータス“送信済み”における最初のセットである分離入力が生成される。
個々のキー処理の成功および失敗の後に、個別の暗号システムはプロトコルメッセージを生成し中央支払保証システム（ＺｉｎＳセントラルシステム）に送信する。この配布はＪＭＳキューによって、あるいはデータベース複製によって行われる。
【０１５７】
中央支払保証システムの領域において、メッセージは受信された後で前記のプロトコル入力のアップデートに用いられる。この目的のために、ステータス“処理成功”／“失敗”および、あるいはエラーコードとメッセージもが保存される。
【０１５８】
プロトコルメッセージの処理に続いて、全ての暗号システムによって組み込みが成功した配布ジョブが存在するかどうかが確認される。存在する場合、特に値転送センターの領域内の、付随するキーの放出が初期化される。システムがエラーを報告したらすぐに、負の状態を持つ対応するエラーメッセージが値転送センターの領域内において生成される。
キー放出が呼び出されているという事実は配布ジョブによって注意され、これによって与えられたジョブに追加の放出は実行されない。しかし警告が長く入力されないほど、放出サービスへの接触の新たな試行が一定の間隔で行われる。
【０１５９】
定義された期間の後、好ましくは数日後、例えば３日後に、全ての暗号システムからのフィードバックが受信されない場合に、特別な変形が存在する。この期間の終了後に、負の放出メッセージが値転送センターに送信される。
【０１６０】
キー割り当てシステムが、管理者にキー配布ジョブのステータスを確認することを可能とするユーザーインターフェースを持つことが好ましい。個々の配布ジョブについて以下のデータが表示される。
・配布メッセージが送信されたシステムの数
・処理成功が報告されたシステムの数
・処理の結果が報告されていないシステムの数
・処理の失敗が報告されたシステムの数
【０１６１】
さらに、個々のシステムの現在のステータスが表示される詳細な表を作成可能である。
代替として、割り当てカード上に保存されるキーを局所的に表示することも可能である。
【０１６２】
配布ジョブを生成された全てのキーを中央支払保証システムの領域においてアーカイブすることが有利である。局所システムにおいてはアーカイブを行わないことが好ましい。ここで、キーはカードの不揮発性メモリーに保存する。同様に放出されたキーメッセージのみをアーカイブする。
【０１６３】
特定の暗号システムについて、移送キーおよびデータキーのキー復旧は中央で可能である。この場合、アーカイブからの現在のキーが確認され、特定の暗号システムへ送信される。この目的のために、プロトコルメッセージも同様に生成される。この形式のキー配布において、放出メッセージのみは存在しない。
【０１６４】
マスター移送キーＫＴＭが消失した場合、対応する暗号システムが新たな初期化のために安全性管理者への送信を行うか、あるいは安全性管理者がサイト上で各システムを初期化しなければならない。
【０１６５】
ウェブセントリーカードの特別な安全性手段、複数のスマートカードへの配布、および多段キーシステムによって、マスター移送キーＫＴＭは漏洩に対し確実に安全性を保証される。
しかし、マスター移送キーの置換が行われた場合は、新たなマスター移送キーＫＴＭおよび新たな署名キー、移送キー、データキーが生成されなければならない。
【０１６６】
これらを局所支払保証システムの全ての暗号システムへと受け入れなければならない。全ての暗号システムが中央管理サイトへの移送を行いこれを戻さなければならず、あるいは安全性管理者が局所支払保証システムの全てのサイトへ移動しなければならないので、これはより多くの労力を伴う。したがって、マスター移送キーＫＴＭについての本発明による安全性機構を利用することは特に有利である。
先のマスター移送キーＫＴＭはいわゆる”潜在ＬＭＫ“としてカード上に残り、これは安全性管理者によって適当に消去されなければならない。
【０１６７】
キーの取り扱いと解読は埋め込みコードとしてカード上に存在するべきである。この様式では、高い安全性が達成できるだけでなく暗号システムの性能向上が期待できる。
【０１６８】
暗号カードは提示された拡張とともに、下に列記した標準ＰＫＣＳ＃１１の機能を含むことが好ましい。
・Ｃ＿ＣｌｏｓｅＳｅｓｓｉｏｎ
・Ｃ＿ＧｅｔＳｌｏｔＬｉｓｔ
・Ｃ＿Ｉｎｉｔ
・Ｃ＿Ｉｎｉｔｉａｌｉｚｅ
・Ｃ＿Ｌｏｇｉｎ
・Ｃ＿Ｌｏｇｏｕｔ
・Ｃ＿ＯｐｅｎＳｅｓｓｉｏｎ
【０１６９】
さらに、恒常的に保存される機能はサードパーティーのさらなる拡張を含むべきではなく、ここで要求される拡張は支払保証システムの暗号カードの機能としてのみ統合される。
【０１７０】
ＰＫＣＳ＃１１ ＤＬＬの潜在キー取り扱い手法を指定するために、これらの手法に接頭辞を与える。この接頭辞はＣＥ＿として定義される。ここで、ＣＥは暗号の拡張（Ｃｒｙｐｔｏ Ｅｘｔｅｎｓｉｏｎ）を表す。
【０１７１】
各埋め込み手法は形式ＣＫ＿ＲＶの戻り値を供給し、これはｐｋｃｓ１１．ｈ包含ファイルの固定の構成要素として定義される。埋め込み手法の実装の間において、追加のエラー戻り値が定義され、統合のためのＣ＋＋ヘッダーファイル内に設けられる点で有利である。この方法は、埋め込み手法の呼び出しを通して、ハードウェア上に組み込まれた様々なＰｋｃｓ１１を呼び出せる点で有利である。ここでの別の利点は、暗号カードのソフトウェア内での完全に新しく確立されたキーの取り扱いである。
【０１７２】
［この手法の構文法を説明する例］
ＣＫ＿ＲＶ ＝ ＣＥ＿ＭｅｔｈｏｄＮａｍｅ （ｐａｒａｍｅｔｅｒ ｌｉｓｔ）
パラメータリスト内において、結果で埋められる必要のあるパラメータは参照による呼び出しによって転送される。手法の名前は有意味な語の組み合わせによって形成され、該手法が行うことの正しい意味を示す。
語の選択は内容を意味する関連付けを許容するように、例えば英語の技術用語の使用によってなされる。
【０１７３】
２つの計数形式の導入により、異なる埋め込み手法の機能性が証明される。キーの形式と属性について、該計数形式の間には相違がある。
ＣＥ＿ＥｎｕｍＫｅｙ ＝ ｛ ＣＥ＿ＫＴ， ＣＥ＿ＤＴ， ＣＥ＿ＳＥ， ＣＥ＿ＫＡ ｝
【０１７４】
ＣＥ＿ＫＡは特別な位置を仮定する。これは１つのキーではなく全てのキーのセットである。このＥｎｕｍＥｌｅｍｅｎｔが示されると、手法はカード内に含まれる全てのキーに関連する機能性を実装する。
ＣＥ＿ＥｎｕｍＫｅｙＡｔｔｒｉｂｕｔｅ ＝ ｛ ＣＥ＿ＩＤ， ＣＥ＿ＬＡＢＥＬ， ＣＥ＿ＳＴＡＲＴＤＡＴＥ， ＣＥ＿ＥＮＤＤＡＴＥ ｝
【０１７５】
必要な定義はｐｋｃｓ１１．ｈファイルへと引き継がれる。定義された拡張はｐｋｃｓ１１．ｈファイルに封入された分割ヘッダーファイル内に位置させることができる。埋め込み手法の実装のためには様々な機構が可能である。
【０１７６】
暗号環境において、関連する証明はそれに利用可能なＰＫＣＳ＃１１手法によって自律的に実行される。
ＣＫ＿ＲＶ ＣＥ＿Ｄｅｃｒｙｐｔ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ ［ ］ ｍｅｓｓａｇｅ， ＣＫ＿ＢＹＴＥ＊ ｐｏｓｔａｇｅＩＤ
ＣＫ＿ＢＢＯＯＬ ｂＯｋ）
【０１７７】
［機能の説明］
埋め込み暗号手法パラメータメッセージ内の５７バイトの長期の日付を受信し、この日付は郵便証印のマトリクスコードに対応する。以下の作業手順の説明における計数は１から始まる。
【０１７８】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターとして、最初の２バイトは０で埋められ、バイトｆ６からｆ１０およびｆ１４がマトリクスコードに付加される。
【０１７９】
［第２の手順：用いるＫＤの決定］
キー位相インジケーターはバイトｆ１４に含まれ、どのキーが用いられるかを表示する。キー位相インジケーターはＣＫＡ＿ＩＤキー属性内に保存され、キーを明白に識別する。以下で説明されるキーの取り扱いは効果的なキーの発見を可能とすべきである。
【０１８０】
［第３の手順：含まれる暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭにおいて使用される機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣである。バイトｆ１５からｆ３８の２４バイトが解読され、解読結果の最初の１２バイトがパラメータのＰｏｓｔａｇｅＩＤによって出力される。解読が成功すると、手順４あるいは手順５の手順が繰り返される。
【０１８１】
［第４の手順：ハッシュ値の形成とクリーンアップ］
特別に構成された７７バイトの大きいデータブロックが、日付のハッシュ値の形成の根拠となる。
バイト１から５３：マトリクスコードの最初の５３バイトに対応
バイト５４から６５：現在の暗号化されていないメッセージ部分（ＰｏｓｔａｇｅＩＤ）の最初の１２バイトに対応
バイト６６から７７：現在の暗号化されていないメッセージ部分の最後の１２バイトに対応
ハッシュ値はＳＨＡ−１を用いて形成され、この手続きの後で最初の４バイトがバイトｆ５４からｆ５７に一致しなければならない。一致しない場合、日付は正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順５となる。
【０１８２】
［第５の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
ＣＫ＿ＲＶ ＤＥ＿ＶｅｒｉｆｙＭｓｇ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ ［ ］ ｍｅｓｓａｇｅ， ｉｎｔ ｌｅｎｇｔｈ，
ＣＫ＿ＢＢＯＯＬ ｂＯｋ）
【０１８３】
証明手続きの一般的なデータブロックメッセージを以下に示す。
【０１８４】
【表９】
【０１８５】
未使用のフィールドはゼロで埋められる。手法の操作の様式はパラメータＭｓｇＴｙｐｅによって決定される。
生成されたデータブロックはＭｓｇＴｙｐｅのＫＴおよびＫＤへのメッセージに転送される。データブロックは個々の受信されたメッセージで埋められる。
【０１８６】
ＭｓｇＴｙｐｅのＫＴへの機能割り当てＣＥ＿ＶｅｒｉｆｙＭｓｇ ＫＴはＭＥＳＳＡＧＥ属性内の完全な移送キーメッセージ、およびＬＥＮＧＴＨ属性内のその長さを受信する。この埋め込みメッセージは受信者における移送キーメッセージの保全性を保証する。証明の動作のために、以下の手順を行う必要がある。
【０１８７】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターはゼロで埋められる。
【０１８８】
［第２の手順：受信した暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭで用いる機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤである。可変ＭＡＣフィールドのバイトが解読される。解読の間にエラーが起こった場合は、手続きは手順４となる。
【０１８９】
［第３の手順：ハッシュ値のクリーンアップ］
日付のハッシュ値の形成のために、移送キーメッセージのフィールド１＋２＋５＋６＋８からハッシュを形成し、これを手順２のハッシュと比較する。ＳＨＡ−１に使用するハッシュ値が形成される。ハッシュ値が同一でない場合は、日付が正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順４となる。
【０１９０】
［第４の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
【０１９１】
ＭｓｇＴｙｐｅ ＫＤについての機能割り当てＣＥ＿ＶｅｒｉｆｙＭｓｇの後で、ＭＥＳＳＡＧＥ属性内の完全な移送キーメッセージ、およびＬＥＮＧＴＨ属性内のその長さが転送される。この埋め込みメッセージは受信者における移送キーメッセージの保全性を保証する。証明の動作のために、以下の手順を行う必要がある。
【０１９２】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターはゼロで埋められる。
【０１９３】
［第２の手順：受信した暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭで用いる機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤである。可変ＭＡＣフィールドのバイトが解読される。解読の間にエラーが起こった場合は、手続きは手順４となる。
【０１９４】
［第３の手順：ハッシュ値のクリーンアップ］
日付のハッシュ値の形成のために、データキーメッセージのフィールド１＋２＋４＋３＋６＋７＋８からハッシュを形成し、これを手順２のハッシュと比較する。ＳＨＡ−１に使用するハッシュ値が形成される。ハッシュ値が同一でない場合は、日付が正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順４となる。
【０１９５】
［第４の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
【０１９６】
これらの埋め込みキー取り扱い手法はラップされたキーの受け入れおよび効果的なキー管理を含むべきである。形式ＫＳ、ＫＤおよびＫＴのキーが受け入れられるべきである。
ＣＫ＿ＲＶ ＣＥ＿ＩｍｐｏｒｔＫｅｙ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ＿ＰＴＲ ｄａｔａ，
ＣＫ＿ＵＬＯＮＧ ｌｅｎｇｔｈ， ＣＫ＿ＢＹＴＥ＊ ＨａｓｈＶａｌｕｅ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ＣＫ＿ＣＨＡＲ ［ ］ ＫｅｙＫＴＩＤ）
【０１９７】
機能割り当てＣＥ＿ＩｍｐｏｒｔＫｅｙは以下に述べるように行われることが好ましい。
ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ＷＥＢＳＥＮＴＲＹ機構がラッピングに用いられる。よって、ラッピングを解くためには同様の機構が必要である。得られたキーはラッピング解除によって暗号ハードウェアに受け入れられ、２回目に受け入れられたキー、つまり同一のキー位相を持つキーによって、古いキーが上書きされる。
【０１９８】
ラップされたキーはＤＡＴＡパラメータに転送され、ＬＥＮＧＴＨ属性内のその長さが転送される。キーの長さはキー属性の充填に依存する。キー形式はＫｅｙＴｙｐｅパラメータによって証明され、これによって処理される。
その後キーはキャッシュ操作内に保持されたキー管理に移され、利用可能であれば、複製の前者は消去される。
【０１９９】
ＫｅｙＫＴＩＤパラメータによって識別されたＫＴにより、ＤＴは解読され、他の全てのキー形式についてこのパラメータは考慮されず、ゼロで埋められる。
ＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性の従属は重要である。それは前者のキーの日付を示す。
【０２００】
受け入れられたキーのキー属性は、それによってＳＨＡ−１を用いてハッシュ値を形成する乱数を含む。ハッシュ値は埋め込み手法のＨａｓｈＶａｌｕｅパラメータに戻される。ハッシュ値はキー確認メッセージに必要である。
【０２０１】
ラップ解除機構あるいはハッシュ形成の間のエラーにおいて、適当なエラーコードが戻り値あるいはＣＫＲ＿ＯＫに出力される。
ＣＫ＿ＲＶ ＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ｉｎｔ＊ ｃｏｕｎｔｅｒ）
【０２０２】
機能割り当てＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔは、個々のキー形式のキーがどれだけキャッシュ操作内のキー管理のカード上に登録されているかを示す。この様式においては、以下に述べる手法によってキー属性を読み出すことができる。
この方法は以下のように定義される。
ＣＫ＿ＲＶ ＣＥ＿ＧｅｔＡｔｔｒｉｂｕｔｅ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ＣＥ＿ＥｎｕｍＫｅｙＡｔｔｒｉｂｕｔｅ ＫｅｙＡｔｔｒｉｂｕｔｅ，
ｉｎｔ ｐｏｓ，
ＣＫ＿ＢＹＴＥ ［ ］ ＊ ａｔｔｒｉｂｕｔｅ，
ｉｎｔ＊ ｌｅｎｇｔｈ）
【０２０３】
キー形式はＫｅｙＴｙｐｅパラメータと、キーの形式によって暗号ハードウェア上の異なるキー形式が異なるリストに記録されるときに読まれる表によって決定される。
【０２０４】
ＫｅｙＡｔｔｒｉｂｕｔｅパラメータによって読み出される属性が指定され、ＩＴＥＭパラメータによって表の中の始点が示される。最初にその最大値を、全てのキーあるいは１つのキー形式についてＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔ手法を用いて獲得しなければならない。ＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性が出力されると、最後の現在のキーが（同じ形式の新たなキーが受け入れられるまで）理論上無限に正当であり、またそのＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性において同一のキー形式の前者のキーの終了日付を含み、そしてこの示されたキーのＣＫＡ＿ＥＮＤ＿ＤＡＴＥが出力される。
【０２０５】
日付についての属性は８バイトの固定された長さを有するのに対し、ＣＳＫ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性は１２８バイトの固定された長さを有する。これらの２つのパラメータについてのキー内の属性が１２８バイトより短い場合は、１２８までの残りのバイトは０で埋められる。したがって、ユーザーは常に当該の手法に充分なメモリーを提供できる。ユーザーの提供するバッファーが小さすぎる場合は、情報はトリミングされ、この結果のメッセージがＣＫ＿ＲＶによって伝達される。
ＣＫ＿ＲＶ ＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ｉｎｔ＊ ｃｏｕｎｔｅｒ）
【０２０６】
機能割り当てＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓはカード内の失効したキーを探し、これをカードから消去する。失効したキーはシステム日付が後継のキーのＣＫＡ＿ＥＮＤ＿ＤＡＴＥ（２．５．８参照）より古いことによって識別され、これはＫＴおよびＫＳにも適用される。選択的消去はＥｎｕｍＴｙｐｅによって可能となり、ＣＥ＿ＫＡによってカード全体を消去できる（ＬＭＫのみ保持される）。この手法はキーの受け入れの実行の際には有効化を許容されないことが重要である。これは埋め込みコード内で制御され、適当な戻り値で示されることが好ましい。この方法により、内部キー管理において不確定な副作用が回避される。
サイドチャネルからの改ざんの可能性を除外するために、支払保証システムと値転送センターとの間のインターフェースは厳密であることが好ましい。
【０２０７】
値転送センター（郵便料金ポイント）と中央支払保証システムとの間のインターフェースの構造を図３に示す。
値転送センター（郵便料金ポイント）のＫｅｙＭａｎａｇｅｍｅｎｔ構成要素において生成されるキーが支払保証システムの暗号システムに配布可能であることにより、キー配布のためのインターフェースが中央支払保証システムに設けられる。
キーの配布成功と処理の後で支払保証システムがキーを放出可能であることにより、値転送センターによって支払保証システムにキー放出インターフェースが設けられる。
【０２０８】
両計画において主にＪａｖａ（登録商標）を用いているので、セッションビーンを用いる適用インターフェースの実現が推奨される。２つのシステムを分離するために、サービスはＪＮＤＩを用いて指定のサービスで調べるべきである。
【０２０９】
キーデータをＺｉｎＳセントラルシステムに受け入れるために必要な機能性がセッションビーンによって提供される。全体の通信は図４に示される。
データキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための処理手順が図４に示される。
【０２１０】
処理ルーチンＩｍｐｏｒｔＫｅｙによってデータキーセットがＺｉｎＳセントラルに転送される。
ＡＳＮ．１メッセージを使用することで、この処理ルーチンは受信メッセージを準備し、メッセージをデータベースに保存させる。処理ルーチンＩｍｐｏｒｔＫｅｙはそれからＣＷＭＳによるキーデータのＺｉｎＳローカルシステムへの配布を初期化する。
【０２１１】
データのデータベースへの受け入れシーケンスとそれに続くメッセージの配布は監視されるべきである。これによって受信されたデータが作業の前に安全性を保証される。この方法の利点は、エラーの領域のイベントをよりよく再構成でき、データの消失の場合には必要ならデータベースにアクセスできることである。
【０２１２】
この時点においてＡＳＮ．１フォーマットがサポートされているかが不明瞭なので、ＩｎｓｅｒｔＫｅｙＤａｔａ手法のパラメータはまだ指定されていない。しかし、詳細なメッセージを郵便料金ポイントにも送信可能とするためには２つのパラメータが装備されなければならないであろう。
【０２１３】
ＺｉｎＳセントラルにおいて、キー割り当てシステムの配布手法は下記の原因となる。
【０２１４】
１． ＺｉｎＳセントラルサーバー上でのキーメッセージのアーカイブ。
【０２１５】
２． ＶｉｂｒｉｓによるＣＷＭＳインターフェースによる、郵便料金ポイントから個別のメールセンターへのキーメッセージの配布。ＣＷＭＳの構造と利用はこのインターフェースの説明書に見られる。
【０２１６】
３． 個々のメールセンターへの配布と受け入れが完了した後に、付随する返送メッセージを生成する。
【０２１７】
データは値転送センター（郵便料金ポイント）からＡＳＮ．１フォーマットで伝達される。付随する応答も同様にＡＳＮ．１フォーマットと予想される。しかし、このフォーマットの代わりに他のフォーマットを用いることももちろん可能である。特定のフォーマットは適当なパーサーによって使用のために適用される。
ＡＳＮ．１の好ましいデータフォーマットは以下のものである。
【０２１８】
［移送キーの配布メッセージ］
ＴｒａｎｓｐｏｒｔＫｅｙＭｅｓｓａｇｅ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＭｓｇＴｙｐｅ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ｆｉｘ ‘ＫＴ’ ）
Ｖｅｒｓｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ）
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ）
ＳｉｇＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＳｉｇｎａｔｕｒｅＫｅｙ ｕｓｅｄ ｆｏｒ ＭＡＣ ）
ＴｒａｎｓＫｅｙＥｎｃｒｙｐｔ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＴｒａｎｓｐｏｒｔＫｅｙ ｗｒａｐｐｅｄ ｗｉｔｈ ＬＭＫ ）
ＭＡＣ ＯＣＴＥＴ ＳＴＲＩＮＧ （ ＭＡＣ ｏｖｅｒ ａｌｌ ｐｒｅｖｉｏｕｓ ｅｌｅｍｅｎｔｓ ）
【０２１９】
［データキーの配布メッセージ］
ＰｏｓｔａｇｅＫｅｙＭｅｓｓａｇｅ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＭｓｇＴｙｐｅ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ｆｉｘ ‘ＫＤ’ ）
Ｖｅｒｓｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ）
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ）
ＫｅｙＧｅｎｅｒａｔｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ａｓｃｅｎｄｉｎｇ ）
ＳｉｇＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＳｉｇｎａｔｕｒｅＫｅｙ ｕｓｅｄ ｆｏｒ ＭＡＣ）
ＴｒａｎｓＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＴｒａｎｓｐｏｒｔＫｅｙ ）
ＤａｔａＫｅｙＥｎｃｒｙｐｔｅｄ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＰｏｓｔａｇｅＫｅｙ ｗｒａｐｐｅｄ ｗｉｔｈ ＬＭＫ
ａｎｄ
ｅｎｃｒｙｐｔｅｄ ｗｉｔｈ ＴｒａｎｓｐｏｒｔＫｅｙ ）
ＭＡＣ ＯＣＴＥＴ ＳＴＲＩＮＧ （ ＭＡＣ ｏｖｅｒ ａｌｌ ｐｒｅｖｉｏｕｓ ｅｌｅｍｅｎｔｓ ）
｝
Ａｌｓｏ ｓｅｅ ｓｅｃｔｉｏｎ ２．４．６．
【０２２０】
［放出メッセージ］
ＫｅｙＥｘｃｈａｎｇｅＲｅｃｅｉｐｔ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ｒｅｃｅｉｖｅｄ ｋｅｙ ）
ＫｅｙＬａｂｅｌＨａｓｈ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＳＨＡ−１ ｈａｓｈ ｏｆ ＣＫＡ＿ＬＡＢＥＬ ｏｆ ｒｅｃｅｉｖｅｄ ｋｅｙ ）
Ｓｔａｔｅ ＢＯＯＬＥＡＮ， （ ＴＲＵＥ／ＦＡＬＳＥ ｔｏ ｅｎａｂｌｅ／ｄｉｓｍｉｓｓ ｋｅｙ ）
Ｍｅｓｓａｇｅ ＯＣＴＥＴ ＳＴＲＩＮＧ （ Ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ ｓｕｃｃｅｓｓ／ｆａｉｌｕｒｅ ）
｝
【０２２１】
データ構造は異なるセットアップを持つことができる。しかし、考慮される全ての情報の伝達を許容し、また小さいデータの送信の労力の説明となるので、提示された実施例におけるセットアップは特に有利である。特に、データはＣＷＭＳによって、好ましくは郵便サービス提供者のメールセンター内にある、局所支払保証システムへと伝達される。
【０２２２】
ＡＳＮ．１フォーマットが用いられる場合、データはまず内部キーメッセージに解析されなければならず、このドキュメント内に定義されるメッセージが直接使用される場合にはそれは不要となる。
【０２２３】
ＣＷＭＳによって受信されるデータパケットは、以前にこのドキュメント内に定義されたキーメッセージに対応する。これらのメッセージはそれから、最初にタイトル“データキーＫＤの属性”の上のデータ表に適合された後で、埋め込みコードのＶｅｒｉｆｙＭｓｇ手法に従属される。証明の後で、キーの受け入れが埋め込みコードによって開始され、あるいは適当なエラーメッセージが生成される。ＣＥ＿ＩｍｐｏｒｔＫｅｙ埋め込みコード手法における受け入れデータ構造の点において、キーメッセージとページ１２から１４を比較する。古いキーの消去と更新は前期の埋め込みコード手法によって自動的に行われ
【０２２４】
失効したキーを暗号ハードウェアから毎日除去するＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓが毎日呼び出される事が必要である。受け入れの間に、複製キーが消去され新しいものと置き換えられることがＣＡ＿ＩｍｐｏｒｔＫｅｙ手法によって保証される。
埋め込みコード手法はＪａｖａ（登録商標）クラス ＣｒｙｐｔｏＡｄａｐｔｅｒｓによってアプリケーションに結び付けられる。ＣｒｙｐｔｏＡｄａｐｔｅｒｓは、埋め込みコードおよび他のＰＫＣＳ＃１１手法が提示する（同様に指定された）全ての手法を提示する。
【０２２５】
ＪＮＩによって、Ｚａｘｕｓに提供されるＤＬＬを静的に連結したＤＬＬ（ＣｒｙｐｔｏＡｄａｐｔｅｒ．ＤＬＬ）が用いられる。静的連結によって安全性リスクがさらに最小化される。
【０２２６】
ＪＮＩインターフェースのＣ＋＋実装によって、個々の要求されたセッションのエラーの取り扱いが提供される。これに関連してＰＣＦＭデザインドキュメントの“マルチスレッディング”下のステージ３を参照。暗号ハードウェアをマルチスレッディングモードにおいて初期化し、作業者がＤＬＬに登録されエラー取り扱いが作業者に特異的に確立された結果として、ログインの後で個々の作業者が自身のセッションを得る（ｇｅｔＳｅｓｓｉｏｎ， Ｃ＿ＧｅｔＳｅｓｓｉｏｎ）ことで、作業者の構想が支援される。ＤＬＬの本流はログインによって移動され、Ｐｋｃｓ＃１１手法および埋め込み手法の実行のためのエラー取り扱いを同様に有する。
【０２２７】
実装の概観を図６に示す。キーリスト、および埋め込み手法によって提供されるコードは除去される。あるいは、構造のセットアップは同一であるように選択されなければならない。
【０２２８】
［ＤＬＬの接続］
好ましい封入と有利なエラー取り扱いの例を図７に示す。
キーリストが暗号ハードウェアの埋め込みコードに完全に保持されている場合は、キーリストの実装は必要ない。ＧｅｔＡｔｔｒｉｂｕｔｅ手法は単一の埋め込みＣＥ＿ＧｅｔＡｔｔｒｉｂｕｔｅ手法に削減される。同じ理由で、受け入れのための呼び出しおよび実装も、必要なデータの転送の後で埋め込みコードによって自動的に行われるので削減される。
【０２２９】
拡張されたエラー定数リストが埋め込みコード内に設けられる。
郵便料金ポイントからのキーメッセージがＺｉｎＳセントラルのデータベースに保存され、欠陥のある局所支払保証システムの後での置き換えを可能としている。第一にそのようなメッセージをデータベースに組み込むことが要求され、第二に管理情報が受信される。
その結果、以下のデータベース表が必要となる。
【０２３０】
【表１０】
【０２３１】
郵便料金ポイントに受信されることでキーデータがキーメッセージを保存し、局所支払保証システムの不良の場合、キーメッセージのアーカイブによって、アーカイブされたキーを受け入れることで不良の局所支払保証システムが残りの局所支払保証システムと調整される。保存の前にメッセージをＡＳＮ．１によって解析し局所システムに伝達する必要がある。分割された形態のデータレコードは保存様式として好ましい。これは、ＣＥ＿ＶｅｒｉｆｙＭｅｓｓａｇｅ埋め込み手法に用いられるデータブロックを説明する表に対応する。
【０２３２】
【表１１】
【０２３３】
このデータレコードは重要性を有する。これは第一にメールセンター、好ましくは郵便サービス提供者の郵送システムに統合された全てのメールセンターの局所支払保証システムから受信されたフィードバックを評価するとともに、配布手続きの間に時間が超過すれば常に、可能なエラー解析およびシステムオペレータへの警告を行う。
【０２３４】
同じ理由で、この表は管理情報処理を要する。適用可能であれば、これは入力ＳＮＩｔｅｍＮｏを用いて付随するＴｒａｎｓｐｏｒｔＫｅｙＤａｔａおよび個別の（８３）メールセンターのＴｒａｎｓｐｏｒｔＫｅｙＲｅｐｌａｙＭｅｓｓａｇｅの割り当てと評価を可能とする。
【０２３５】
【表１２】
【０２３６】
この表において、局所支払保証システムの個別の応答メッセージは郵便サービス提供者のメールセンター内に受け入れ手続きの機能としてアーカイブされる。
【図面の簡単な説明】
【０２３７】
【図１】本発明によるキーの配布の特に好ましい実施例を示す図。
【図２】本発明によるキー配布システムの適用例を示す図。
【図３】中央支払保証システム（ＺｉｎＳセントラルシステム）と値転送センター（郵便料金ポイント）との間のインターフェースの概略図。
【図４】データキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための手順を示す図。
【図５】付随する暗号を含む、中央支払保証システム（ＺｉｎＳセントラルシステム）から局所支払保証システムへのキーの配布の概略図。
【図６】ＤＬＬインターフェースの接続状態を示す概略図。
【図７（Ａ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【図７（Ｂ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【図７（Ｃ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、料金納付キーを用いて生成され郵便物に添付される郵便証印の信頼性証明の方法に関する。該郵便証印に含まれる暗号情報を解読し、郵便証印の信頼性証明に用いる。
【背景技術】
【０００２】
デジタル郵便証印を有する郵便物の作成手続きは公知である。
郵便物の差出人がデジタル郵便証印をより容易に作成できるように、例えば、ドイチェポストＡＧの用いる料金納付システムによって、顧客のシステムにおいて郵便証印を作成し、望ましいインターフェースを介してそれをプリンターから出力することが考えられる。
この形式のための方法の１つが、ドイツ予備出願公開ＤＥ １００ ２０ ４０２ Ａ１において開示されている。
【０００３】
この方法の不正な使用を避けるために、デジタル郵便証印は、例えば該郵便証印の作成を制御する顧客のシステムの識別に関する暗号情報を含むものとする。
【０００４】
国際特許ＷＯ ０１／１７１６０ Ａ１はキー配布の手法に関し、ここでキーは中央管理ユニットによって生成され、暗号化された形式で配布ユニットによって暗号装置へと伝達される。これらの装置は、キーの受信の成功あるいは失敗についてのメッセージを配布ユニットから管理ユニットへと送信する。キーを受信できない場合は、暗号化していない形式で再度付随の暗号装置へと送信する。
【０００５】
欧州特許ＥＰ ０ ８５４ ４４４ Ａ２において、料金納付装置によって作成された郵便証印の暗号化と確認のための手法が開示されている。ここでは、料金納付装置に実装されたマスターキーから追加のキーが派生され、郵便証印の作成に用いられる。メールセンターにおいても、追加のキーは同様に生成され郵便証印の確認に用いられる。
【０００６】
米国特許５，１５０，４０８号において、暗号化したメッセージをキー配布ユニットによって通信装置に伝達する、例えば無線ネットワーク等の、通信システムにおけるキー配布のための手法が開示されている。このメッセージが受信された後で、通信装置がキー配布ユニットへと確認を送信する。
【０００７】
暗号化したデータの伝達のための既知の規格ＡＮＳＩ Ｘ９．１７（１９９４年１０月７日付けのＵＲＬ ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｎｉｓｔｐｕｂｓ／８００−７／ｎｏｄｅ２０９．ｈｔｍｌを参照）は複数のキーのキー階層構造に基づいている。ここでは、電子的に置換され通信パートナーの間で暗号化されて伝達される寿命の短いデータの暗号化のための１つ以上のデータキーと、該データキーの暗号化のための手動で置換されるキーが存在する。さらに、引用文献においてデータの暗号化のための既知のディフィーヘルマン手法が開示され、ここで通信パートナーは既知の数と秘密の乱数から共有キーを計算する。
【０００８】
欧州特許ＥＰ ０ ７３５ ７２２ Ａ２において、料金納付装置のためのキーの生成、配布および管理のためのキー管理システムが開示されている。ここでは、複数の高信頼領域が存在し、これらは該領域間の通信を可能とし該領域を制御するコンピュータに接続されている。キーの生成、インストール、証明および確認はそれぞれ高信頼領域の１つにおいて行われる。個々の領域は該領域のステータスをプロトコル処理したアーカイブに統合される。
【０００９】
この発明は、郵便証印の信頼性を素早く確実に証明可能とする方法の考案、という目的に基づいている。特に、該方法は大規模な、とりわけメールセンターまたは貨物センターでの証明手続きにおける利用に適していることが好ましい。
【発明の開示】
【００１０】
本発明によってこの目的は、請求項１による方法により達成される。
詳細には、信頼性証明の方法を、データキーを生成し中央データベース（ＺｉｎＳセントラルシステム）から局所支払保証システム（ＺｉｎＳローカル）へと伝達することが提供される。これは生成された料金納付キーと郵便物に添付された郵便証印を用いてなされ、郵便証印に含まれる暗号情報を解読して該郵便証印の信頼性の証明に用いる。
【００１１】
該方法の安全性を高めるためには、局所支払保証システムがデータキーを受け入れ、受け入れの結果を中央データベース（ＺｉｎＳセントラルシステム）に伝達することが有利である。
【００１２】
この方法の特に好ましい実施形態においては、受け入れの結果はデータレコードとして伝達される。
該データレコードはキーを含むことが好ましい。該キーには様々な属性を持たせることができる。特に、対称キーまたは非対称キーとすることができる。意図して使用することによって、該キーは情報の解読および／または暗号化に用いることができる。その性質によって、該キーによって情報を伝達することもできる。例えば、キーには料金納付キー、そのキーの生成、および／またはその終了日付に関する情報を持たせることができる。
【００１３】
キーの均質な置換を保証するためには、中央データベース（ＺｉｎＳセントラルシステム）において受け入れの結果を確認し、それを値転送センター（郵便料金ポイント）に伝達することが有利である。
【００１４】
前記方法のこの実施形態によって、受け入れの結果の機能として、値転送センターでのさらなる処理手順の実行が可能となる。
【００１５】
この結果は様々な方法で確認される。しかし、結果をキーの解読によって確認することが特に有利である。
【００１６】
前記方法の好ましい実施形態は、まずデータキーをほぼ全ての局所支払保証システム（ＺｉｎＳローカル）へと受け入れ、値転送センターにおいて該データキーを新たな料金納付キーとして放出し、続いて新たな郵便証印の作成に用いることを特徴とする。
前記方法のこの実施形態によって、支払保証システムで先に行われたキーの置換の機能としての値転送センターでのキーの置換が可能となる。この方法によって、既に局所支払保証システムに存在していた新たなキーを用いてのみ郵便証印が作成されることが保証される。これによって、局所支払保証システムにより個々の生成された郵便証印の信頼性を証明可能であることが保証される。
【００１７】
前記方法の、この特に好ましい実施形態は、局所支払保証システムでのキーの置換の機能としての値転送センターでのキーの置換の制御を伴うが、これを少なくともいくつかの本発明に関する他の処理手順と組み合わせることが特に有利である。
特に、複数の特徴の組み合わせによって、キーの置換を素早く確実に行われることと、個々のキーの置換の実行が証明されることとが保証される。
【００１８】
キーの置換が行われる際に、新たなデータキーを値転送センター（郵便料金ポイント）から中央支払保証システムへと伝達することが有利である。
ここで、値転送センターにおいてデータキーを移送キー（ＫＴ）を用いて暗号化することが特に有利である。
ここで、移送キーをマスター移送キー（ＫＴＭ）を用いて暗号化することが実際的である。
【００１９】
データキーは値転送センター内で生成することが好ましい。これにはデータキーが値転送センターへの移送中に不正に変化されることを防止できるという利点がある。
データの安全性をさらに高めるためには、データキーをキー識別情報とともに提供することが有利である。
キー識別情報もまた暗号化した形式で伝達することが有利である。
【００２０】
個々の暗号化および／または解読の手順において正当なデータキーが用いられていることを保証するためには、データキーを生成カウンターとともに提供し、さらに／あるいは生成カウンターとともに伝達することが有利である。
【００２１】
無効なキーの使用を避けるためには、料金納付キーを先のデータキーの終了日とともに提供し、さらに／あるいは終了日とともに伝達することも有利である。
【００２２】
前述のデータキーは１つ以上の部分的な証明や、郵便証印の作成、および／または郵便証印に含まれる情報の解読に用いることができる。
【００２３】
郵便証印に含まれる暗号情報の解読を部分的な証明に含むことが特に有利である。
【００２４】
暗号情報の解読を証明手順に統合することで、郵便証印の信頼性を確認し、証明をリアルタイムで行うことが可能となる。
【００２５】
さらに、部分的な証明の１つが暗号情報の作成の日付と現在の日付との比較を含むことが有利である。郵便証印の作成の日付の、特に暗号化された形式での統合がデータの安全性を高める。それは、郵便証印の作成の日付と現在の日付との比較によって郵便証印の二重使用を防止できるからである。
【００２６】
証明速度のさらなる向上のためには、読み取りユニットと証明ユニットとが同期プロトコルによって情報を交換することが有利である。
本発明の別の同様な実施形態においては、読み取りユニットと証明ユニットとは非同期プロトコルによって互いに通信する。
【００２７】
ここで、読み取りユニットから証明ユニットへとデータ電文を送ることが特に有利である。
該データ電文は郵便証印の内容を含むことが好ましい。
【００２８】
本発明のさらなる利点、特徴および実際的な改良は、従属する請求項と図面に基づいて説明される以下の好ましい実施形態の提示とから見つけることができる。
【００２９】
図１は本発明によるキーの配布の特に好ましい実施例である。
図２は本発明によるキー配布システムの適用例である。
図３は 中央支払保証システム（ＺｉｎＳセントラルシステム）と値転送センター（郵便料金ポイント）との間のインターフェースの概略図である。
図４はデータキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための手順である。
図５は付随する暗号を含む、中央支払保証システム（ＺｉｎＳセントラルシステム）から局所支払保証システムへのキーの配布の概略図である。
図６はＤＬＬインターフェースの接続である。
図７はコンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図である。
【発明を実施するための最良の形態】
【００３０】
以下において本発明を、ＰＣ料金納付システムに関して説明する。ここで、支払保証のための手順は、郵便証印の作成に用いられるシステムから独立している。
個別の証明ステーション、特にメールセンターにおける前記の分散証明が特に好ましいが、集中証明も同様に可能である。
【００３１】
本発明の特に好ましい実施例においては、前記の個別の証明ステーションは局所支払保証システムとし、これらは好ましくはデータ接続によって中央支払保証システムに接続される。
前記の特に好ましい実施例において、中央支払保証システムはまた値転送センターにも接続される。
値転送センターの特に好ましい実施例を、以下において郵便料金ポイントと呼ぶ。中央支払保証システムの有利な実施例を、以下においてＺｉｎＳセントラルと呼ぶ。
【００３２】
値転送センターと支払保証システムとの間に実装される技術的インターフェースは、暗号キーの置換からなる。
【００３３】
転送センターと支払保証システムとの間で置換されるキーは、作成された郵便証印が偽造ではないことを保証する。これは、郵便証印を形成する二次元バーコードの一部を該キーによって暗号化することで達成される。能力による理由のために、選択されたキーは対称キーなので、転送センターから支払保証システムへと伝達される必要があり、そこから個別のメールセンターに配布される。
【００３４】
キーの高信頼保存は特別な暗号カードを用いることによって保証される。本発明は、これらのキーをこの特別なハードウェアを用いて管理する複数の適用例を包含する。これらのキーの生成から送出、配布、分散システムへの受け入れまでの全体の寿命は、プロセスパラメータの最適化のために用いられる。
【００３５】
キー配布のための特に好ましいシーケンスを図１に示す。
図１に、値転送センターと中央支払保証システムとの間での特に好ましいキー配布を示す。
郵便証印の作成に用いられる料金納付キーの置換のための最初の手順１において、まず新たな料金納付キーが生成される。
【００３６】
前記のキーは郵便証印の生成のための異なるやり方に用いることができるので、ここで料金納付キーという語を限定した意味で理解することはできない。
例えば、料金納付キーを直接郵便証印の作成のために用いることができる。
【００３７】
しかし、改ざんに対して特に安全性の高いシステムによって、多重に暗号化したデータ内容を有する郵便証印を作成することも、可能であり特に有利である。ここで該データ内容は好ましくは複数の操作によって形成され、１つ以上の場所で操作の結果を料金納付キーとともに郵便証印に組み込む。
例えば、ドイツ予備出願公開ＤＥ １００ ２０ ４０２ Ａ１に開示される形式の暗号文字列は料金納付キーに組み込まれる。
【００３８】
郵便証印の不正な作成に対し防御をさらに向上するために、料金納付キーのイベント特有の置換を行う。
提示された例において、料金納付キーは所定の間隔をあけて、例えば事前に定義できる時間間隔の満了の後で、新たに生成される。
【００３９】
しかし、料金納付キーの新たな生成を他のパラメータの機能として、例えば郵便物の課金額および／あるいは支払済みの郵便物に基づいて行うことも可能である。
【００４０】
原則の問題として、新たな料金納付キーの新たな生成はどこでも行える。しかし、データの安全性を高めるためには、新たな料金納付キーの伝達の労力を最小限とし、キーを値転送センター内で、あるいは値転送センターの領域内で生成することが有利である。
【００４１】
不正に対する方法の高レベルでの防御を保証するためには、郵便証印に含まれる情報を局所支払保証システムの領域内、例えばメールセンターまたは貨物センター内において料金納付キーに基づいて解読することが有利である。
これを保証するために、料金納付キーを値転送センターから中央支払保証システムへと伝達する。この伝達は自動化することが好ましい。
【００４２】
置換は支払保証システムのサーバー（ＺｉｎＳセントラルサーバー）を介して実施することが好ましい。値転送センター（郵便料金ポイント）を設定する必要はない。サーバーは値転送センター（ＺｉｎＳローカルシステム）とそれに属する暗号システムを認識する必要がないので、ＺｉｎＳセントラルサーバーのみが前記サーバーとして重要である。
【００４３】
好ましい対称型の料金納付キーの新たな生成の後で、後者は中央支払保証システムへと安全に伝達され（図１の手順２）、そこから局所支払保証システム内の暗号システムへと配布される（図１の手順３）。局所支払保証システム内から受け入れ操作の結果が返送され（図１の手順４）、キーの受け入れの成功が確認される。結果を中央システムでコンパイルし、確認し値転送センター（郵便料金ポイント）へと伝達する（図１の手順５）。
【００４４】
キーの全ての局所支払保証システム内の暗号システムへの受け入れが成功すると、値転送センター（郵便料金ポイント）において放出され、続いて新たな郵便料金額の生成に用いられる（図１の手順６）。
【００４５】
好ましい対称型の料金納付キーは、料金納付キーを用いて作成される郵便証印の偽造への安全性において不可欠な部分であり、該郵便証印は例えば二次元バーコードの形式とする。したがって、これらのキーの置換は強力な暗号法によって安全を確保する必要がある。これを保証するためには、以下の点を支持することが特に重要である。
・内容の機密性：伝達の間に、第三者が伝達されるキーを読み出すことが可能であってはならない。さらに、キーが安全に保存され、第三者による読み出しが不可能であることも保証されなければならない。後者の機能性はウェブセントリー（ＷｅｂＳｅｎｔｒｙ）の暗号カードによって保証される。
・内容の保全性：第三者がキーの一部を偽造することが可能であってはならない。
・認証：双方の通信パートナーは差出人／受取人の認証が正しいことを確認しなければならない。受取人の見地からは、これはキーが郵便料金ポイントにおいて生成されたということを意味する。差出人の見地からは、正当なＺｉｎＳローカル暗号システムのみがキーを受信できることが保証されなければならない。
【００４６】
提示された対称型の方法において、双方の通信パートナーは同一のキーＫＴを持つ。値転送センター（郵便料金ポイント）はキーＫＴを用いて、伝達されるデータキーＫＤを暗号化し、それからデータキーＫＤを支払保証システム（ＺｉｎＳセントラルシステム）のサーバーへと転送する。
【００４７】
それからこのキーをさらに中央支払保証システムから局所支払保証システムのＺｉｎＳローカル暗号システムへと移送する。これらのシステムもキーＫＴにアクセスし、それによってキーＫＤを再び解読できる。キーＫＤを移送の間に安全に防御するためにキーＫＴを用いるので、キーＫＴも以下において移送キーと呼ぶ。
【００４８】
全ての局所支払保証システムが同じデータを受信するので、個々の局所暗号サーバーと値転送センター（郵便料金ポイント）との間で別々の移送キーＫＴを定義する必要がない。しかし、安全性の理由から、このキーＫＴはデータキーＫＤのように一定の間隔で更新するべきである。しかし、キーＫＤではあまり多くのテキストを暗号化しないので、交換の間隔は長くすることができる。１年または２年の交換間隔が、ここでは特に有利である。
【００４９】
この方法の不可欠な構成要素は移送キーＫＴの置換であり、これは安全性の理由から、データキーＫＤの置換と同じチャンネルで行うべきではない。この置換は手動では行わない。この手続きは複数の局所支払保証システムについて一定間隔で行わなければならないので、移送キーの置換も自動化できるように、ここで別の手法を提供しなければならない。
【００５０】
この目的のために、ＡＮＳＩ規格Ｘ９．１７（金融サービスのための対称手法に基づいたキー管理）において、マスター移送キー（以下、ＫＴＭと呼称）と呼ばれる別のキーレベルが定義されている。このキーは特別な安全性警戒の元で暗号カードにインストールしなければならず、また拡大した間隔において置換しなければならない。ここで、全てのシステムに同じＫＴＭがインストールされる。それからこのキーで移送キーＫＴを暗号化し、その後キーＫＴを同じチャンネルによって自動化された様式で配布し、受け入れを行う。該配布はデータキーの配布と同様に行われる。個別のシステムまたはその暗号カードの初期化については以下の節で詳述する。
【００５１】
メッセージの保全性と差出人（郵便料金ポイント）の認証を保証するために、個別のキーメッセージにマトリクスコード（ＭＡＣ）が形成される。ＭＡＣの生成のために、ＫＴＭと同様に暗号カードの初期化の間に受け入れられる署名キーＫＳが必要となる。データキーメッセージの署名は、その後でこのキーＫＳによってなされる。ドイチェポストのイントラネット内での伝達の間におけるメッセージの機密性は、強い暗号手法を用いることでこのように確保される。メッセージの暗号化と解読の特に好ましい手法はトリプルＤＥＳ（キー長１６８ビット）である。ハッシュ値はＳＨＡ−１アルゴリズムによって計算することが好ましい。
【００５２】
郵便料金ポイントと支払保証システムの暗号システムに存在する正当性の様々な周期を、データキーの配布と保存のために考慮しなければならない。最大２つのキーＫＤが所定の時間において郵便料金ポイントで利用可能でなければならない。つまり、１つのキーは現在正当であり、新たに生成された郵便料金額を伴うもう１つのキーは暗号化される（ＫＤｎｅｗ）。
【００５３】
該キー（ＫＤｎｅｗ）による既存のキーの操作の‘置換’モードにおいて、新たなキーが支払保証システムの暗号システムに伝達される。このキーを全ての局所支払保証システムの暗号システムに受け入れ成功してから、ＺｉｎＳセントラルシステムの放出メッセージが生成され、この時点において、ＫＤｎｅｗが郵便料金ポイントの新たな郵便料金額の暗号化に用いられる。この時点において、古いＫＤは郵便料金ポイントから消去すべきであり、またこれ以上新たな郵便料金額の生成に用いられるべきではない。
【００５４】
局所支払保証システムの暗号システムでは状況は異なる。ダウンロードされた郵便料金額は事前に定義できる時間の周期、例えば３ヶ月にわたって郵便証印の作成に使用でき、複数のキーＫＤが郵便証印の証明に利用可能でなければならない。
【００５５】
さらに、キーの配布の際には、暗号システムに受け入れられず郵便料金ポイントにおいて有効化できなかったキーに何があったのかも考慮すべきである。これらのキーを他の暗号システムに受け入れさせることが可能であり、原則の問題として、さらなる証明の間についても考慮すべきである。
【００５６】
ここで、キーの明瞭な更新と可能な最も単純なシステムのメンテナンスを許容する一様な状態に達するためには、以下のキー配布の手法の実行方法の形式が特に好ましい。
（ａ）データキーは暗号化された形式で、確定したキーＩＤ（キー位相表示）、不確定な生成カウンター、および正当先行データキーとともに伝達される。
（ｂ）値転送センター（郵便料金ポイント）からのデータキーの個々の伝達は、中央支払保証システムで確認メッセージによって確認されるべきである。
（ｃ）確認が正だった場合は、全ての局所支払保証システムへのデータキーの受け入れは成功していて、顧客はキーを利用してＰＣ料金納付を行うことができる。
この場合、生成カウンターは続くキーの伝達のたびに増加する。
（ｄ）確認が負だった場合は、全ての局所支払保証システムへのデータキーの受け入れは成功しておらず、値転送センターは顧客のシステムに郵便証印を作成させるべきではない。でなければ正当な郵便物が多量に転用される危険があるためである。
この場合、生成カウンターは続くキーの伝達のたびに増加しない。すなわち、先の伝達の値のままとなる。
（ｅ）確認がない場合は、その間、値転送センター（郵便料金ポイント）はこれ以上の中央支払保証システム（ＺｉｎＳセントラル）へのキー伝達が不可能となる。（このような試行は当然、支払保証システムによって却下されるが、値転送センター内で阻止すべきである）
（ｆ）延長された時間周期にわたって支払保証システムによる確認がない場合（タイムアウト超過）、値転送センター（郵便料金ポイント）はその直接あるいは間接のユーザーインターフェースによって警報を出すことができる。
（ｇ）暗号カードがデータキーを受信したらすぐに、最前の伝達としての同じ生成カウンター値を持つデータキー全てを消去する。これによって、エラーによる伝達が多数の場合、かつて暗号カードへの読み込みに成功したキーのみが消去される。トランザクションの安全なキー伝達が許容される。
（ｈ）局所支払保証システムの暗号カードにおいて、ルーチンが繰り返し、好ましくは定期的に、特には日毎に呼び出され、それは既に必要でなくなったデータキーを消去する。続くデータキーに関してＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性に保存された終了日付が現在のシステムデータより小さい際に、データキーは（（ｇ）や他の有利な実施例において）消去される。
（ｉ）先のキーの終了日付になると、（できるだけ短い）猶予期間が計画されるべきである。それは、局所支払保証システムの領域で確認されると、失効した郵便料金額とともに作成された郵便証印が、その正当性が終了した後でまださらに２日間正当だと認識されるためである。さらに、新たなデータキーの生成と放出のタイムラグも考慮しなければならない。
【００５７】
図２において現在のキーの管理の適用領域とその支払保証の領域における利用の概観が示される。さらに、適用の好ましい領域が提示される。
以下において適用例を詳述する。
【００５８】
続いて、前述のキー管理手法の詳細を提示する。
前述の適用は、暗号カードを用いる例によって提示する。
【００５９】
まず、値転送センターの領域において暗号カードを初期化する方法を提示する。
・製造業者の範囲においては、カードのインストールと設定、カードのファームウェアのアップロードはまだなされていない。ファームウェアの機能性は埋め込まれたコード（著作権のあるソフトウェアルーチン）によって拡張される。安全性の理由から、ＰＫＣＳ＃１１（公開鍵暗号基準）によるキールーチン（生成、消去等）はユーザーによって阻止されるべきである。これにより、カードにおいてより高いキーの安全性が保証される。
・（複数の暗号カードを有する）クラスターの定義。
・局所マスターキーＬＭＫの生成と保存。ＬＭＫは３つ以上の成分に配布されるべきであり、成分の２つは暗号サーバーカードの再形成または初期化に特に有利である。個々の成分はスマートカードにＰＩＮ防御によって書き込まれることが好ましく、そして安全性管理者はスマートカードを受け取る。なお、バックアップのスマートカードも作成すべきである。その後、ＬＭＫを前記のマスター移送キーＫＴＭとして用いる。
・ユーザー管理：デフォルトの安全性管理者の消去と、（スマートカードに基づく）必要な認証規則を含む安全性管理者の定義。
・初期の署名キーＫＳの生成、ＫＴＭによる暗号化（ラップ）およびファイルとしての保存。このファイルのディスケットへの後のコピーは可能とすべきである（ファイル／ディスケットへのアクセスは安全性管理者にのみ可能とすべきである）。
・最初の移送キーＫＴの生成、付随するキーメッセージの創作、およびメッセージのファイルへの保存とその後での該ファイルのディスケットへのコピー（アクセスは安全性管理者にのみ可能とすべきである）。
【００６０】
［移送マスターキーの生成］
新たな移送マスターキー（ＫＴＭ）は以下に述べる様式で生成することが望ましい。付随する確認カードの局所マスターキー（ＬＭＫ）をＫＴＭとして用いる。安全性の理由から、ＬＭＫは３つ以上の成分に分割されるべきであり、成分の２つ以上は再受け入れに必要である。
【００６１】
個別の成分をスマートカードに保存し、個々の安全性管理者はスマートカードを受け取り個々のＰＩＮによりその安全性を確保する。ＰＩＮの機密を維持しスマートカードを安全な場所に保存することで、権限のない者がそれらにアクセス可能となることを防ぐ。
【００６２】
移送マスターキーの実装のために、２つ以上のＬＭＫ成分（２つの異なる認可カードに関する）が存在することが好ましく、これによって二重制御原則の自動的な実装が実行される。
【００６３】
ＫＴＭはトリプルＤＥＳキーでなければならない。キーのＩＤ属性は型式識別および確定した数からなる。
型式識別：ＫＴ
確定した数：０１から９９
長さ：固定４バイトがＣＫ＿ＣＨＡＲ［ ］として保管される。
【００６４】
原則の問題として、認可された者のみがキーを置換可能であることを保証するために、様々な安全性機構が適している。しかし、以下で述べる署名キーを用いる実施例は、改竄操作に対する特に高い安全性をもたらすので、特に有利である。
【００６５】
署名キーはキーメッセージの保全性を保証する。これはまた、キーメッセージの差出人が郵便料金ポイントであるかどうかを確認するのにも利用できる。署名キーの生成は、スマートカードで登録された安全性管理者にのみ可能とすべきである。これは、ＴＲＵＥに設定された‘感受性’とＦＡＬＳＥに設定された‘抽出’の安全性属性を有し、キー平文がカード外部で発見されることを防ぐＴＤＥＳキーであるべきである。キーのＩＤ属性は型式識別および確定した数からなる。
型式識別：ＫＳ
確定した数：０１から９９
長さ：固定４バイトがＣＫ＿ＣＨＡＲ［ ］としてファイルされる。
【００６６】
キーは送出のためにＫＴＭでラップする必要があり、それからディスケット上にファイルとして保存される。ディスケットは安全な場所に置かねばならず、暗号カードの初期化に用いる。キーファイルの保全性は、好ましくはラップに用いるカードに保存される、処理ルーチンによって保証される。
【００６７】
移送キーＫＳの好ましい属性は以下の表に編集される。
【００６８】
【表１】
【００６９】
ＬＡＢＥＬ属性の乱数は暗号サーバーカードへの受け入れ成功の確認に用いられる。ハッシュ値（例えばＳＨＡ−１による）はこの乱数のために形成され、受け入れ成功の確認と移送キーの放出のために用いられる。
【００７０】
ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲとしてファイルされる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００７１】
署名キーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化され、ＬＭＫのようにサイト上のハードウェアにアップロードされる。
【００７２】
移送キーの生成について以下で述べる。
この適用例においては、付随するキーメッセージを含む移送キーが生成される。
移送キーおよび／または付随するキーメッセージは安全性管理者によってのみ初期化可能なようにキー生成モジュールを設定することが好ましい。置換間隔は１年または２年とすべきである。
【００７３】
次に、移送キーは、以下の属性設定を備えるＴＤＥＳキーである。
【００７４】
【表２】
【００７５】
ＬＡＢＥＬ属性の乱数は暗号サーバーカードへの受け入れ成功の確認に用いられる。ハッシュ値（例えばＳＨＡ−１による）はこの乱数のために形成され、受け入れ成功の確認と移送キーの放出のために用いられる。
【００７６】
ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲとしてファイルされる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００７７】
移送キーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化され、値転送センターから中央支払保証システムへの伝達のために以下の構造を持つメッセージが形成される。
【００７８】
【表３】
【００７９】
さらなる配布に続いて、この移送キーメッセージはＺｉｎＳセントラルサーバーへと転送される。インターフェースはセッションビーンによって実現され、このサービスは指定のサービス（Ｊａｖａ Ｎａｍｉｎｇ ａｎｄ Ｄｉｒｅｃｔｏｒｙ Ｉｎｔｅｒｆａｃｅ−ＪＮＤＩ）によって調べられる。移送の手法は前記のデータブロックを要求すべきである。
【００８０】
さらに、メッセージを郵便料金ポイントにファイルとして保存し、安全性管理者はこれを後で、安全な場所に保存される１つ以上のディスケットに保存することができる。ディスケットはそれから暗号サーバーカードの初期化に用いられる。
【００８１】
移送キーの放出の好ましい実施例を以下に説明する。
値転送センターは移送キーＫＴを放出可能に設定される。移送キーＫＴの放出のために、全ての局所支払保証システム（ＺｉｎＳ暗号システム）への配布と受け入れが成功した移送キーを中央値転送センターから放出可能なインターフェースがある。放出によってのみ、付随する移送キーが続いてデータキー（ＫＤ）の暗号化に用いられる。
【００８２】
前記インターフェースはセッションビーンとして実現される。このサービスは指定のサービスによって調べられる。
放出手続きのデータ構造は以下のパラメータを有することが好ましい。
【００８３】
【表４】
【００８４】
ＰＰキー管理システムに対する支払保証システムのキー割り当てシステム（ＺｉｎＳキー管理システム）の認証はパラメータ２で行われる。これはＳＨＡ−１の手法を用いて移送キーのＬＡＢＥＬ属性から形成されるハッシュ値である。ＬＡＢＥＬ属性は移送キーの生成の際に乱数で埋められる。移送キーとその全ての属性は伝達の間に暗号化されるので、ＺｉｎＳ暗号サーバーのみが正しいハッシュ値を計算できる。
【００８５】
伝達されたハッシュ値がＬＡＢＥＬ属性のために計算されたＫＴのハッシュ値と同一の場合、該ハッシュ値は郵便料金ポイントウェブセントリーモジュールに位置され、伝達された処理ステータスが真の場合、移送キーは有効化される。これは、続いてデータキーメッセージが移送キーを用いて暗号化されることを意味する。
【００８６】
処理が誤っている（伝達されたステータスが偽である）場合には、この適用例の変形が存在する。この場合、このキー生成とキー配布のためのステータスがプロトコル処理され、付随する移送キーはこれによって消去される。
【００８７】
新たなデータキーの生成の好ましい例を以下に示す。
この適用例においては、付随するキーメッセージを含むデータキーが生成される。キー割り当てシステムは、この動作が安全性管理者によってのみ初期化可能なように設定される。これは３ヶ月毎に行われるべきである。中央支払保証システム（ＺｉｎＳセントラルシステム）からフィードバック（放出またはエラー）が受信されておらず、データキーＫＤが流通している場合、フィードバックが受信されるまで新たなＫＤの生成は阻止される。
【００８８】
データキー（ＫＤ）は特定のマトリクスコード内容の暗号化を行い、また支払いが郵便サービス提供者になされていない場合は正当な郵便証印を作成できないことを保証する。このデータキーによってＺｉｎＳ暗号サーバーにおいてデジタル郵便証印が証明される。データキーは、ＰＫＣＳ＃１１機能Ｃ＿ＧｅｎｅｒａｔｅＫｅｙを用いて生成され以下の属性を持つＴＤＥＳキーと同様である。
【００８９】
【表５】
【００９０】
ＣＫＡ＿ＩＤ属性の値と生成カウンターはシステムに規定される。ＣＫＳ＿ＩＤは上方へ１ずつカウントされるが、生成カウンターはキーの放出が成功したときのみ増加する。ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲ ［ ］として埋められる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００９１】
ＬＡＢＥＬ属性の乱数によって暗号サーバーカードへの受け入れの成功が確認される。この乱数のためにハッシュ値が（ＳＨＡ−１によって）形成され、移送キーの受け入れの成功の確認と放出に用いられる。
【００９２】
データキーの置換のためのメッセージの生成はいくらか複雑で、以下のシーケンスを含む。
【００９３】
１． データキーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化される。これには、キーの全ての属性（特にＣＫＡ＿ＥＸＴＲＡＣＴＡＢＬＥ＝ｆａｌｓｅ）が同時に暗号化され、解読の際に正しく再設定されるという利点がある。この暗号化されたバイトシーケンスを用いて、以下の構造を持つ仮のメッセージが形成される。
【００９４】
【表６】
【００９５】
２． 次に、仮のメッセージは有効な移送キーＫＴによって、ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構を用いて暗号化される（初期化ベクターはゼロで埋める）。
【００９６】
３． 配布されるメッセージを形成し、それは以下の構造を有するものとする。
【００９７】
【表７】
【００９８】
４． その後、データキーメッセージをＺｉｎＳセントラルサーバーへのさらなる配布のために転送する。さらに、安全性管理者によって１つ以上のディスケットに保存し、それを安全な場所に保管して、新たなＺｉｎＳ暗号カードの初期化に使用できるようにする。
【００９９】
メッセージ内容の二重暗号化の利点は、暗号化の少ないテキストはインターネット経由でＫＴＭに伝達しなければならず、したがってこのキーの暗号解析がはるかに困難になる、ということである。
【０１００】
データキーＫＤの放出のために、インターフェースとプロトコル機構を設け、データキーの放出をプロトコル処理する。データキーの局所支払保証システムへの配布と受け入れの成功の後にのみデータキーを放出するように中央支払保証システムを設定することが好ましい。この放出によってのみ、付随するデータキーは続いて暗号文字列の暗号化に用いられ、郵便証印に組み込まれ付随キー識別情報ＫｅｙＩＤを郵便料金額の識別情報（ＰｏｓｔａｇｅＩＤ）の中で暗号化する。
【０１０１】
インターフェースは中央支払保証システム（ＺｉｎＳセントラル）と局所支払保証システム（ＺｉｎＳローカル）との間のＣＷＭＳ（コンピューター作業管理システム）によって実現される。値転送センター（郵便料金ポイント）ＰＰは適切なビーンから情報を受信する。放出手続きのためのデータ構造は以下の内容を有する。
【０１０２】
【表８】
【０１０３】
値転送センターＰＰのキー割り当てシステムに対する、支払保証システムのキー割り当てシステムの認証は、パラメータ２によって行われる。これはＳＨＡ−１の手法を用いて移送キーのＬＡＢＥＬ属性から形成されるハッシュ値である。ＬＡＢＥＬ属性は移送キーの生成の際に乱数で埋められる。データキーとその全ての属性は伝達の間に暗号化されるので、支払保証システムの暗号サーバーのみが正しいハッシュ値を計算できる。
【０１０４】
伝達されたハッシュ値がＬＡＢＥＬ属性のために計算されたＫＤのハッシュ値と同一の場合、該ハッシュ値は郵便料金ポイントウェブセントリーモジュールに位置され、伝達された処理ステータスが真の場合、移送キーは有効化される。これは、続いて郵便証印／郵便料金額のための暗号文字列がこのデータキーを用いて暗号化されることを意味する。データキーが有効化されると、署名キーの生成カウンターが１つずつ増加する。
【０１０５】
処理が誤っている（伝達されたステータスが偽である）場合、この適用例の変形が存在する。この場合、このキー生成とキー配布のためのステータスがプロトコル処理され、付随する移送キーはカードから消去される。この場合、署名キーの生成カウンターが１つずつ増加することはない。
【０１０６】
キー割り当てシステムは実行されたキー生成を保存するステータスメモリーを有することが好ましい。実行されたキー生成のついて中央支払保証システム（ＺｉｎＳセントラルシステム）からのフィードバックが受信されていないと、ステータスが開いて表示される。フィードバックと配布が成功すると、有効化されているとしてキーが指定される。エラーの場合は、伝達されたステータスメッセージが表示される。エラーあるいは放出メッセージの不在が延長された場合、エラー調査ルーチンが呼び出される。
【０１０７】
キーをアーカイブすることが有利である。値転送センターの領域における好ましいキーのアーカイブについて以下で説明する。キーの安全性を保証するために、安全性管理者は全てのキー（ＫＴＭを除く）をＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化して返送するアーカイブ機能を開始することができる。これらのキーはデータベースまたは安全ファイルシステム領域に安全に保存されるべきである。
アーカイブの成功の後で、初期正当性日付を６ヶ月以上過ぎて既に有効でない全てのキーが消去される。
【０１０８】
特に値転送センターＰＰの領域において、キーは復旧され、アーカイブされたキーデータは解読され（ラップを解かれ）カードに保存される。ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構が再び用いられる。
キーが解読された後で、既にカードに存在していた同一のキー識別情報ＫｅｙＩＤを有するキーは消去される。
【０１０９】
ウェブセントリーカードの特別な安全性手段と複数のスマートカードへの配布によって、マスター移送キーＫＴＭは漏洩に対し確実に安全性を保証される。
にもかかわらずマスター移送キーの置換がなされる場合は、“暗号カード”（ＰＰ）の初期化を含む適用例と同様に、新たなＫＴＭと新たな署名キー、移送キーおよびデータキーを生成しなければならない。
先のＫＴＭはいわゆる“潜在ＬＭＫ”としてカードに残され、安全性管理者によって適当に消去されなければならない。
【０１１０】
キー割り当てシステムの好ましい適用例を以下で説明する。提示は支払保証システムの全ての領域に適用される。これは特に個別の構成要素が、好ましくは局所支払保証システムまたは中央支払保証システムの領域に実装される場合に有利である。しかし、他の支払保証システムにおける使用も同様に可能である。
【０１１１】
第１の適用例は支払保証システムの領域における暗号カードの初期化である。
暗号カードの初期化のために以下の基本的な設定が用いられ、機能性の大半は管理ツール（ウェブセントリーマネージャー（ＷｅｂＳｅｎｔｒｙＭａｎａｇｅｒ））で管理できる。
・製造業者が既に行っていない範囲での、暗号カードのインストールと設定、カードファームウェアのアップロード。ファームウェアは埋め込まれたコード（著作権のあるソフトウェアルーチン）を有する。（後の機能性はウェブセントリーマネージャーに統合される）
・クラスターの定義づけ（複数の暗号カードを用いる）（ウェブセントリーマネージャー）
・移送マスターキー（ＫＴＭ）の受け入れ、分離適用例を参照（機能性はウェブセントリーマネージャーによって提供される）
・ユーザー管理：デフォルトの安全性管理者の消去と、（スマートカードに基づく）必要な認証規則を含む安全性管理者の定義
あらかじめ定義されたＰＩＮによって認可される、２つの“通常”ユーザーの生成（１つはキー証明のため、もう１つはキー受け入れのため）
ユーザー管理の機能性は同様にウェブセントリーマネージャーによって提供される。
・署名キー（ＫＳ）の受け入れ：分離適用例を参照
・移送キー（ＫＴ）の受け入れ：分離適用例を参照
・随意のデータキー（ＫＤ）の同様な受け入れ：（同様にその適用例を参照）すでに生成された範囲内
【０１１２】
キーは以上で定義したシーケンスにおいて受け入れられなければならない。カードは中央において初期化可能で、完全な暗号システムコンピューターを初期化し、その後送らなければならない。これはウェブセントリーカードがＰＣＩスロットから引き抜かれるとすぐに内部の記憶を消去するからである。
【０１１３】
暗号システムに対しスマートカードリーダーと関連したスマートカードで局所的に識別された２人以上の安全性管理者によってのみ、移送マスターキーを受け入れることが可能であることが好ましい。キーＫＴＭの重要性のために、このキーは二重制御原理を用いてのみカードに受け入れ可能とする。これは適用例“移送マスターキー”において生成された２つ以上のＰＩＮ防御スマートカードが受け入れに必要であることを意味する。
【０１１４】
マスター移送キーＫＴＭは双方のスマートカードを用いてのみ読み込み可能で、キーの使用はＰＩＮ防御されているため、このキーは二重制御原理を用いてのみカードにインストール可能であることが保証される。これによって違法なキーに対し非常に高い水準の防御を提供できる。
【０１１５】
この機能性は管理ツール、ウェブセントリーマネージャーによって提供される。この管理ツールによって、いわゆる局所マスターキー（ＬＭＫ、この構想において述べられたＫＴＭに対応）をスマートカードから読み出し、カードの安全な保存領域に保存することが可能となる。
【０１１６】
ＬＭＫを３つのスマートカードに配布することが特に有利であり、ＬＭＫを暗号ハードウェアに受け入れるために全ての３つの部分が必要である。この場合、マスター移送キーＫＴＭの受け入れのために３人の安全性管理者が必要である。
【０１１７】
署名キーはキーメッセージの保全性を保証する。これはまたキーの受け入れの前に、キーメッセージの送信者が値転送センター（郵便料金ポイント）であるかどうかを決定することにも使用できる。署名キーは異なる方法で生成することが可能で、ここで提示する例は特に有利なものである。付随キーメッセージは管理者によってディスケット上に保存され、この適用例では、初期化される支払保証システムの暗号カードに受け入れられる。
【０１１８】
キーの受け入れのために、ディスケット上に保存されたキーメッセージをマスター移送キーＫＴＭ（ＰＫＣＳ＃１１機能Ｃ＿Ｕｎｗｒａｐ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて解読する。キーメッセージの保全性はこのルーチンによって自動的に確認される。このキーＩＤを持つキーが既に存在している場合は、続いて削除される。
【０１１９】
移送キーメッセージのさらなる移送のために、中央支払保証システムのサーバーにインターフェースが設けられ、これによって配布とそれに続く個別の支払保証システムの暗号システムへの受け入れを初期化することができる。
【０１２０】
インターフェースはＲＭＩサービスによって実現される。このサービスは指定のサービス（ＪＮＤＩ）によって調べられる。配布はＣＷＭＳ（コンピューター作業管理システム）によって、Ｐ／Ｎリストの配布を用いてなされる。
【０１２１】
新たな配布ジョブが創作されると、キーメッセージは全ての現在登録されている暗号システムに転送され、個々の場合にプロトコルの入力が書き込まれる。暗号システムの管理は支払保証システムの適用例によってなされる。
【０１２２】
新たなキーメッセージの受信は個別の暗合システムにおいて受け入れ制御装置によって一定の間隔でなされる（配布機構の機能として）。新たなメッセージが受信されると、適用例“移送キーの受け入れ”が自動的に実行される。この動作の戻り値を確認する。負のフィードバックを受信した場合は、受け入れの試行を３回まで繰り返す。
【０１２３】
３回の試行の後でまだ受け入れが不可能な場合は、失敗に関するプロトコルメッセージをＺｉｎＳセントラルシステムに送信する（再び移転機構の機能として）。受け入れが成功した場合は、正のプロトコルメッセージが発行される。
プロトコルメッセージは適用例“プロトコルキー処理”によって中央で処理される。移送キーの放出も同様に開始される。
【０１２４】
移送キーの受け入れはサイト上の暗号システムを初期化する安全性管理者によって実行されるか、あるいはこの受け入れは受け入れ制御装置が新たな移送キーメッセージを受信した際に受け入れ制御装置によって自動的に開始されるものとする。キーは以下の処理手順によって受け入れられることが好ましい。
【０１２５】
１． カードへの登録はキー受け入れユーザーに属するＩＤとＰＩＮによってなされる。
【０１２６】
２． ハッシュ値はＳＨＡ−１手法を用いて移送キーのフィールド１から５へと形成される。
【０１２７】
３． 署名キーがフィールド４に表示されるキーＩＤを有していることを確認する。
【０１２８】
４． このキーは上記２で形成されたハッシュ値の暗号化に用いられ（ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）、フィールド６と比較される。これらの２つの値が合致すると、保全性が保証され、メッセージがＰＣ料金納付システムによって創作されたことが保証される。
【０１２９】
５． メッセージのフィールド５の内容はＫＴＭ（Ｃ＿ＵｎｗｒａｐＫｅｙ手法、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）によって解読される。結果、適当な移送キーオブジェクトが自動的に生成されカードに保存される。なお、該機構は再び暗黙のうちにキーの保全性と差出人の正確さを確認する。
【０１３０】
６． カードに同一のキーＩＤを持つキーが既に存在する場合、それは消去される。
【０１３１】
７． 新たに受け入れられたキーのＬＡＢＥＬ属性に、ハッシュ値がＳＨＡ−１手法を用いて形成され、これはキーＩＤおよび戻り値としての正のメッセージとともに返送される。
【０１３２】
８． ユーザーのセッションを終了する。
【０１３３】
９． プロトコルメッセージを戻り値から創作し、ＺｉｎＳセントラルシステムに送信する。
【０１３４】
１０． このキーＩＤのために保存されている失敗した試行がリセットされる。
【０１３５】
この適用例の変形は、ルーチンの１つまたはＭＡＣの確認の失敗である。この場合、さらなる処理は打ち切られ、キーＩＤ、エラーコードおよびエラーメッセージを含む戻り値が返送される。キーＩＤについて、保存されている失敗した試行の数が１つずつ増加する。この数が３に達すると、最も新しく転送された戻り値からプロトコルメッセージが創作され、中央支払保証システムに送信される。
【０１３６】
手動での初期化の場合、さらに受け入れの結果が安全性管理者のモニターに表示される。
手順２から７をカードソフトウェアにおいて直接実行することが好ましい（埋め込みコード）。これによって性能および違法に対する安全性が向上する。
【０１３７】
データキーメッセージのさらなる移送のために、中央支払保証システムのサーバーに、局所支払保証システムの個別の暗号システムへのデータキーの配布とそれに続く受け入れのための新たなインターフェースを設ける。
インターフェースはセッションビーンとして実現され、このサービスは指定のサービス（Ｊａｖａ Ｎａｍｉｎｇ ａｎｄ Ｄｉｒｅｃｔｏｒｙ Ｉｎｔｅｒｆａｃｅ−ＪＮＤＩ）によって調べられる。
【０１３８】
配布はＣＷＭＳ（コンピューター作業管理システム）によって、Ｐ／Ｎリストの配布を用いてなされる。
【０１３９】
新たな配布ジョブが創作されると、キーメッセージは全ての現在登録されている暗号システムに転送され、個々の場合にプロトコルの入力が書き込まれる。暗号システムの管理は支払保証システムの適用例によってなされる。値転送センターＰＰにおいてフィードバックが受信されておらず、データキーの配布ジョブが既に循環している場合は、フィードバックの時点までさらなるデータキーの配布ジョブの受容が拒否される。
【０１４０】
新たなキーメッセージの受信は個別の暗合システムにおいて受け入れ制御装置によって一定の間隔でなされる（配布機構の機能として）。新たなメッセージが受信されると、適用例“移送キーの受け入れ”が自動的に実行される。この動作の戻り値を確認する。負のフィードバックを受信した場合は、受け入れの試行を３回まで繰り返す。
【０１４１】
３回の試行の後でまだ受け入れが不可能な場合は、失敗に関するプロトコルメッセージをＺｉｎＳセントラルシステムに送信する（再び移転機構の機能として）。受け入れが成功した場合は、正のプロトコルメッセージが発行される。
プロトコルメッセージは適用例“プロトコルキー処理”によって中央で処理される。移送キーの放出もこの適用例によって開始される。
【０１４２】
移送キーの受け入れはサイト上の暗号システムを初期化する安全性管理者によって実行されるか、あるいはこの受け入れは受け入れ制御装置が新たな移送キーメッセージを受信した際に受け入れ制御装置によって自動的に開始されるものとする。
【０１４３】
データキーメッセージの特徴を考慮して、キーは移送キーの受け入れと同様にして受け入れられる。
【０１４４】
１． カードへの登録はキー受け入れユーザーに属するＩＤとＰＩＮによってなされる。
【０１４５】
２． ハッシュ値はＳＨＡ−１手法を用いて移送キーのフィールド１から７へと形成される。
【０１４６】
３． 署名キーはフィールド５に表示されるキーＩＤを有することを確認される。
【０１４７】
４． このキーは上記２で形成されたハッシュ値の暗号化に用いられ（ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）、フィールド８と比較される。これらの２つの値が合致すると、保全性が保証され、メッセージがＰＣ料金納付システムによって創作されたことが保証される。
【０１４８】
５． 署名キーはフィールド６に表示されるキーＩＤを有することを確認される。
【０１４９】
６． メッセージのフィールド７の内容を、５で確認されたキーによって解読する（Ｃ＿Ｄｅｃｒｙｐｔ手法、ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）。解読結果が仮のメッセージである。
【０１５０】
７． 仮のメッセージのフィールド１の内容はＫＴＭ（Ｃ＿ＵｎｗｒａｐＫｅｙ手法、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）によって解読される。結果、適当な移送キーオブジェクトが自動的に生成されカードに保存される。なお、該機構は再び暗黙のうちにキーの保全性と差出人の正確さを確認する。
【０１５１】
８． カードに同一のキーＩＤを持つキーが既に存在する場合、それは消去される。
【０１５２】
９． 暗号カードの全てのデータキーを読み込み、ＬＡＢＥＬ属性の生成カウンターの値、バイト１が新たに受け入れられたキーと同一かを確認する。同一であれば、これらのキーをカードから除去する。別の局所支払保証システムの暗号システムへの受け入れにおけるエラーによって、これらのキーは値転送センターＰＰにおいて放出されなかった。
【０１５３】
１０． 新たに受け入れられたキーのＬＡＢＥＬ属性のバイト２から６５に、ハッシュ値がＳＨＡ−１手法を用いて形成され、これはキーＩＤおよび戻り値としての正のメッセージとともに返送される。
【０１５４】
１１． 暗号カードによるユーザーのセッションを終了する。
【０１５５】
１２． プロトコルメッセージを戻り値から創作し、ＺｉｎＳセントラルシステムに送信する。
【０１５６】
１３． このキーＩＤのために保存されている失敗した試行がリセットされる。
【０１５７】
この適用例の変形は、ルーチンの１つまたはＭＡＣの確認の失敗である。この場合、さらなる処理は打ち切られ、キーＩＤ、エラーコードおよびエラーメッセージを含む戻り値が返送される。キーＩＤについて、保存されている失敗した試行の数が１つずつ増加する。この数が３に達すると、最も新しく転送された戻り値からプロトコルメッセージが創作され、中央支払保証システム（ＺｉｎＳセントラルシステム）に送信される。
手動での初期化の場合、さらに受け入れの結果が安全性管理者のモニターに表示される。
【０１５８】
手順２から１０をカードソフトウェアにおいて直接実行することが好ましい（埋め込みコード）。これによって性能および違法に対する安全性（特に初期化ベクターＩＶおよびＫＴＭｓにおいて）が向上する。
データキーのクリーンアップは繰り返し、好ましくは定期的に、支払保証システムの可能な限り多くの、好ましくは全ての暗号システムにおいて行われ、これによって既に不要となったデータキーが消去される。
【０１５９】
［データキーのクリーンアップの手続き］
１． カード上の全てのデータキーＫＤを確認し、そのＩＤ（ＣＫＡ＿ＩＤ属性）によって確認順に分類する。
【０１６０】
２． このリストの各キーについて、以下の確認手続きを行う。
Ｉ． キーの後継を決定する（次に大きいＩＤ）。
ＩＩ． 存在する場合、以下を証明する。
（１） 前者の正当性の終了を示す後継のＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性が現在のシステム日付より小さいかどうか。小さい場合は、リストの現在処理されているキーを消去する。
（２） 後継の生成カウンター（ＣＫＡ＿ＬＡＢＥＬ属性のバイト１）が現在処理されているキーの生成カウンターと同一かどうか。同一の場合は、リストの現在処理されているキーを消去する。
【０１６１】
キー処理は中央支払保証システムのサーバー（ＺｉｎＳセントラルサーバー）においてプロトコル処理されることが好ましい。この適用例によってプロトコル処理されるキーは移送キーとデータキーである。
【０１６２】
個々の配布ジョブについて、キーメッセージが送信された有効な暗号システムを示すプロトコルが作成される。個々のシステムと配布ジョブについて、ステータス“送信済み”における最初のセットである分離入力が生成される。
個々のキー処理の成功および失敗の後に、個別の暗号システムはプロトコルメッセージを生成し中央支払保証システム（ＺｉｎＳセントラルシステム）に送信する。この配布はＪＭＳキューによって、あるいはデータベース複製によって行われる。
【０１６３】
中央支払保証システムの領域において、メッセージは受信された後で前記のプロトコル入力のアップデートに用いられる。この目的のために、ステータス“処理成功”／“失敗”および、あるいはエラーコードとメッセージもが保存される。
【０１６４】
プロトコルメッセージの処理に続いて、全ての暗号システムによって組み込みが成功した配布ジョブが存在するかどうかが確認される。存在する場合、特に値転送センターの領域内の、付随するキーの放出が初期化される。システムがエラーを報告したらすぐに、負の状態を持つ対応するエラーメッセージが値転送センターの領域内において生成される。
キー放出が呼び出されているという事実は配布ジョブによって注意され、これによって与えられたジョブに追加の放出は実行されない。しかし警告が長く入力されないほど、放出サービスへの接触の新たな試行が一定の間隔で行われる。
【０１６５】
定義された期間の後、好ましくは数日後、例えば３日後に、全ての暗号システムからのフィードバックが受信されない場合に、特別な変形が存在する。この期間の終了後に、負の放出メッセージが値転送センターに送信される。
【０１６６】
キー割り当てシステムが、管理者にキー配布ジョブのステータスを確認することを可能とするユーザーインターフェースを持つことが好ましい。個々の配布ジョブについて以下のデータが表示される。
・配布メッセージが送信されたシステムの数
・処理成功が報告されたシステムの数
・処理の結果が報告されていないシステムの数
・処理の失敗が報告されたシステムの数
【０１６７】
さらに、個々のシステムの現在のステータスが表示される詳細な表を作成可能である。
代替として、割り当てカード上に保存されるキーを局所的に表示することも可能である。
【０１６８】
配布ジョブを生成された全てのキーを中央支払保証システムの領域においてアーカイブすることが有利である。局所システムにおいてはアーカイブを行わないことが好ましい。ここで、キーはカードの不揮発性メモリーに保存する。同様に放出されたキーメッセージのみをアーカイブする。
【０１６９】
特定の暗号システムについて、移送キーおよびデータキーのキー復旧は中央で可能である。この場合、アーカイブからの現在のキーが確認され、特定の暗号システムへ送信される。この目的のために、プロトコルメッセージも同様に生成される。この形式のキー配布において、放出メッセージのみは存在しない。
【０１７０】
マスター移送キーＫＴＭが消失した場合、対応する暗号システムが新たな初期化のために安全性管理者への送信を行うか、あるいは安全性管理者がサイト上で各システムを初期化しなければならない。
【０１７１】
ウェブセントリーカードの特別な安全性手段、複数のスマートカードへの配布、および多段キーシステムによって、マスター移送キーＫＴＭは漏洩に対し確実に安全性を保証される。
しかし、マスター移送キーの置換が行われた場合は、新たなマスター移送キーＫＴＭおよび新たな署名キー、移送キー、データキーが生成されなければならない。
【０１７２】
これらを局所支払保証システムの全ての暗号システムへと受け入れなければならない。全ての暗号システムが中央管理サイトへの移送を行いこれを戻さなければならず、あるいは安全性管理者が局所支払保証システムの全てのサイトへ移動しなければならないので、これはより多くの労力を伴う。したがって、マスター移送キーＫＴＭについての本発明による安全性機構を利用することは特に有利である。
先のマスター移送キーＫＴＭはいわゆる”潜在ＬＭＫ“としてカード上に残り、これは安全性管理者によって適当に消去されなければならない。
【０１７３】
キーの取り扱いと解読は埋め込みコードとしてカード上に存在するべきである。この様式では、高い安全性が達成できるだけでなく暗号システムの性能向上が期待できる。
【０１７４】
暗号カードは提示された拡張とともに、下に列記した標準ＰＫＣＳ＃１１の機能を含むことが好ましい。
・Ｃ＿ＣｌｏｓｅＳｅｓｓｉｏｎ
・Ｃ＿ＧｅｔＳｌｏｔＬｉｓｔ
・Ｃ＿Ｉｎｉｔ
・Ｃ＿Ｉｎｉｔｉａｌｉｚｅ
・Ｃ＿Ｌｏｇｉｎ
・Ｃ＿Ｌｏｇｏｕｔ
・Ｃ＿ＯｐｅｎＳｅｓｓｉｏｎ
【０１７５】
さらに、恒常的に保存される機能はサードパーティーのさらなる拡張を含むべきではなく、ここで要求される拡張は支払保証システムの暗号カードの機能としてのみ統合される。
【０１７６】
ＰＫＣＳ＃１１ ＤＬＬの潜在キー取り扱い手法を指定するために、これらの手法に接頭辞を与える。この接頭辞はＣＥ＿として定義される。ここで、ＣＥは暗号の拡張（Ｃｒｙｐｔｏ Ｅｘｔｅｎｓｉｏｎ）を表す。
【０１７７】
各埋め込み手法は形式ＣＫ＿ＲＶの戻り値を供給し、これはｐｋｃｓ１１．ｈ包含ファイルの固定の構成要素として定義される。埋め込み手法の実装の間において、追加のエラー戻り値が定義され、統合のためのＣ＋＋ヘッダーファイル内に設けられる点で有利である。この方法は、埋め込み手法の呼び出しを通して、ハードウェア上に組み込まれた様々なＰｋｃｓ１１を呼び出せる点で有利である。ここでの別の利点は、暗号カードのソフトウェア内での完全に新しく確立されたキーの取り扱いである。
【０１７８】
［この手法の構文法を説明する例］
ＣＫ＿ＲＶ ＝ ＣＥ＿ＭｅｔｈｏｄＮａｍｅ （ｐａｒａｍｅｔｅｒ ｌｉｓｔ）
パラメータリスト内において、結果で埋められる必要のあるパラメータは参照による呼び出しによって転送される。手法の名前は有意味な語の組み合わせによって形成され、該手法が行うことの正しい意味を示す。
語の選択は内容を意味する関連付けを許容するように、例えば英語の技術用語の使用によってなされる。
【０１７９】
２つの計数形式の導入により、異なる埋め込み手法の機能性が証明される。キーの形式と属性について、該計数形式の間には相違がある。
ＣＥ＿ＥｎｕｍＫｅｙ ＝ ｛ ＣＥ＿ＫＴ， ＣＥ＿ＤＴ， ＣＥ＿ＳＥ， ＣＥ＿ＫＡ ｝
【０１８０】
ＣＥ＿ＫＡは特別な位置を仮定する。これは１つのキーではなく全てのキーのセットである。このＥｎｕｍＥｌｅｍｅｎｔが示されると、手法はカード内に含まれる全てのキーに関連する機能性を実装する。
ＣＥ＿ＥｎｕｍＫｅｙＡｔｔｒｉｂｕｔｅ ＝ ｛ ＣＥ＿ＩＤ， ＣＥ＿ＬＡＢＥＬ， ＣＥ＿ＳＴＡＲＴＤＡＴＥ， ＣＥ＿ＥＮＤＤＡＴＥ ｝
【０１８１】
必要な定義はｐｋｃｓ１１．ｈファイルへと引き継がれる。定義された拡張はｐｋｃｓ１１．ｈファイルに封入された分割ヘッダーファイル内に位置させることができる。埋め込み手法の実装のためには様々な機構が可能である。
【０１８２】
暗号環境において、関連する証明はそれに利用可能なＰＫＣＳ＃１１手法によって自律的に実行される。
ＣＫ＿ＲＶ ＣＥ＿Ｄｅｃｒｙｐｔ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ ［ ］ ｍｅｓｓａｇｅ， ＣＫ＿ＢＹＴＥ＊ ｐｏｓｔａｇｅＩＤ
ＣＫ＿ＢＢＯＯＬ ｂＯｋ）
【０１８３】
［機能の説明］
埋め込み暗号手法パラメータメッセージ内の５７バイトの長期の日付を受信し、この日付は郵便証印のマトリクスコードに対応する。以下の作業手順の説明における計数は１から始まる。
【０１８４】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターとして、最初の２バイトは０で埋められ、バイトｆ６からｆ１０およびｆ１４がマトリクスコードに付加される。
【０１８５】
［第２の手順：用いるＫＤの決定］
キー位相インジケーターはバイトｆ１４に含まれ、どのキーが用いられるかを表示する。キー位相インジケーターはＣＫＡ＿ＩＤキー属性内に保存され、キーを明白に識別する。以下で説明されるキーの取り扱いは効果的なキーの発見を可能とすべきである。
【０１８６】
［第３の手順：含まれる暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭにおいて使用される機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣである。バイトｆ１５からｆ３８の２４バイトが解読され、解読結果の最初の１２バイトがパラメータのＰｏｓｔａｇｅＩＤによって出力される。解読が成功すると、手順４あるいは手順５の手順が繰り返される。
【０１８７】
［第４の手順：ハッシュ値の形成とクリーンアップ］
特別に構成された７７バイトの大きいデータブロックが、日付のハッシュ値の形成の根拠となる。
バイト１から５３：マトリクスコードの最初の５３バイトに対応
バイト５４から６５：現在の暗号化されていないメッセージ部分（ＰｏｓｔａｇｅＩＤ）の最初の１２バイトに対応
バイト６６から７７：現在の暗号化されていないメッセージ部分の最後の１２バイトに対応
ハッシュ値はＳＨＡ−１を用いて形成され、この手続きの後で最初の４バイトがバイトｆ５４からｆ５７に一致しなければならない。一致しない場合、日付は正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順５となる。
【０１８８】
［第５の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
ＣＫ＿ＲＶ ＤＥ＿ＶｅｒｉｆｙＭｓｇ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ ［ ］ ｍｅｓｓａｇｅ， ｉｎｔ ｌｅｎｇｔｈ，
ＣＫ＿ＢＢＯＯＬ ｂＯｋ）
【０１８９】
証明手続きの一般的なデータブロックメッセージを以下に示す。
【０１９０】
【表９】
【０１９１】
未使用のフィールドはゼロで埋められる。手法の操作の様式はパラメータＭｓｇＴｙｐｅによって決定される。
生成されたデータブロックはＭｓｇＴｙｐｅのＫＴおよびＫＤへのメッセージに転送される。データブロックは個々の受信されたメッセージで埋められる。
【０１９２】
ＭｓｇＴｙｐｅのＫＴへの機能割り当てＣＥ＿ＶｅｒｉｆｙＭｓｇ ＫＴはＭＥＳＳＡＧＥ属性内の完全な移送キーメッセージ、およびＬＥＮＧＴＨ属性内のその長さを受信する。この埋め込みメッセージは受信者における移送キーメッセージの保全性を保証する。証明の動作のために、以下の手順を行う必要がある。
【０１９３】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターはゼロで埋められる。
【０１９４】
［第２の手順：受信した暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭで用いる機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤである。可変ＭＡＣフィールドのバイトが解読される。解読の間にエラーが起こった場合は、手続きは手順４となる。
【０１９５】
［第３の手順：ハッシュ値のクリーンアップ］
日付のハッシュ値の形成のために、移送キーメッセージのフィールド１＋２＋５＋６＋８からハッシュを形成し、これを手順２のハッシュと比較する。ＳＨＡ−１に使用するハッシュ値が形成される。ハッシュ値が同一でない場合は、日付が正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順４となる。
【０１９６】
［第４の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
【０１９７】
ＭｓｇＴｙｐｅ ＫＤについての機能割り当てＣＥ＿ＶｅｒｉｆｙＭｓｇの後で、ＭＥＳＳＡＧＥ属性内の完全な移送キーメッセージ、およびＬＥＮＧＴＨ属性内のその長さが転送される。この埋め込みメッセージは受信者における移送キーメッセージの保全性を保証する。証明の動作のために、以下の手順を行う必要がある。
【０１９８】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターはゼロで埋められる。
【０１９９】
［第２の手順：受信した暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭで用いる機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤである。可変ＭＡＣフィールドのバイトが解読される。解読の間にエラーが起こった場合は、手続きは手順４となる。
【０２００】
［第３の手順：ハッシュ値のクリーンアップ］
日付のハッシュ値の形成のために、データキーメッセージのフィールド１＋２＋４＋３＋６＋７＋８からハッシュを形成し、これを手順２のハッシュと比較する。ＳＨＡ−１に使用するハッシュ値が形成される。ハッシュ値が同一でない場合は、日付が正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順４となる。
【０２０１】
［第４の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
【０２０２】
これらの埋め込みキー取り扱い手法はラップされたキーの受け入れおよび効果的なキー管理を含むべきである。形式ＫＳ、ＫＤおよびＫＴのキーが受け入れられるべきである。
ＣＫ＿ＲＶ ＣＥ＿ＩｍｐｏｒｔＫｅｙ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ＿ＰＴＲ ｄａｔａ，
ＣＫ＿ＵＬＯＮＧ ｌｅｎｇｔｈ， ＣＫ＿ＢＹＴＥ＊ ＨａｓｈＶａｌｕｅ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ＣＫ＿ＣＨＡＲ ［ ］ ＫｅｙＫＴＩＤ）
【０２０３】
機能割り当てＣＥ＿ＩｍｐｏｒｔＫｅｙは以下に述べるように行われることが好ましい。
ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ＷＥＢＳＥＮＴＲＹ機構がラッピングに用いられる。よって、ラッピングを解くためには同様の機構が必要である。得られたキーはラッピング解除によって暗号ハードウェアに受け入れられ、２回目に受け入れられたキー、つまり同一のキー位相を持つキーによって、古いキーが上書きされる。
【０２０４】
ラップされたキーはＤＡＴＡパラメータに転送され、ＬＥＮＧＴＨ属性内のその長さが転送される。キーの長さはキー属性の充填に依存する。キー形式はＫｅｙＴｙｐｅパラメータによって証明され、これによって処理される。
その後キーはキャッシュ操作内に保持されたキー管理に移され、利用可能であれば、複製の前者は消去される。
【０２０５】
ＫｅｙＫＴＩＤパラメータによって識別されたＫＴにより、ＤＴは解読され、他の全てのキー形式についてこのパラメータは考慮されず、ゼロで埋められる。
ＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性の従属は重要である。それは前者のキーの日付を示す。
【０２０６】
受け入れられたキーのキー属性は、それによってＳＨＡ−１を用いてハッシュ値を形成する乱数を含む。ハッシュ値は埋め込み手法のＨａｓｈＶａｌｕｅパラメータに戻される。ハッシュ値はキー確認メッセージに必要である。
【０２０７】
ラップ解除機構あるいはハッシュ形成の間のエラーにおいて、適当なエラーコードが戻り値あるいはＣＫＲ＿ＯＫに出力される。
ＣＫ＿ＲＶ ＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ｉｎｔ＊ ｃｏｕｎｔｅｒ）
【０２０８】
機能割り当てＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔは、個々のキー形式のキーがどれだけキャッシュ操作内のキー管理のカード上に登録されているかを示す。この様式においては、以下に述べる手法によってキー属性を読み出すことができる。
この方法は以下のように定義される。
ＣＫ＿ＲＶ ＣＥ＿ＧｅｔＡｔｔｒｉｂｕｔｅ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ＣＥ＿ＥｎｕｍＫｅｙＡｔｔｒｉｂｕｔｅ ＫｅｙＡｔｔｒｉｂｕｔｅ，
ｉｎｔ ｐｏｓ，
ＣＫ＿ＢＹＴＥ ［ ］ ＊ ａｔｔｒｉｂｕｔｅ，
ｉｎｔ＊ ｌｅｎｇｔｈ）
【０２０９】
キー形式はＫｅｙＴｙｐｅパラメータと、キーの形式によって暗号ハードウェア上の異なるキー形式が異なるリストに記録されるときに読まれる表によって決定される。
【０２１０】
ＫｅｙＡｔｔｒｉｂｕｔｅパラメータによって読み出される属性が指定され、ＩＴＥＭパラメータによって表の中の始点が示される。最初にその最大値を、全てのキーあるいは１つのキー形式についてＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔ手法を用いて獲得しなければならない。ＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性が出力されると、最後の現在のキーが（同じ形式の新たなキーが受け入れられるまで）理論上無限に正当であり、またそのＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性において同一のキー形式の前者のキーの終了日付を含み、そしてこの示されたキーのＣＫＡ＿ＥＮＤ＿ＤＡＴＥが出力される。
【０２１１】
日付についての属性は８バイトの固定された長さを有するのに対し、ＣＳＫ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性は１２８バイトの固定された長さを有する。これらの２つのパラメータについてのキー内の属性が１２８バイトより短い場合は、１２８までの残りのバイトは０で埋められる。したがって、ユーザーは常に当該の手法に充分なメモリーを提供できる。ユーザーの提供するバッファーが小さすぎる場合は、情報はトリミングされ、この結果のメッセージがＣＫ＿ＲＶによって伝達される。
ＣＫ＿ＲＶ ＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ｉｎｔ＊ ｃｏｕｎｔｅｒ）
【０２１２】
機能割り当てＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓはカード内の失効したキーを探し、これをカードから消去する。失効したキーはシステム日付が後継のキーのＣＫＡ＿ＥＮＤ＿ＤＡＴＥ（２．５．８参照）より古いことによって識別され、これはＫＴおよびＫＳにも適用される。選択的消去はＥｎｕｍＴｙｐｅによって可能となり、ＣＥ＿ＫＡによってカード全体を消去できる（ＬＭＫのみ保持される）。この手法はキーの受け入れの実行の際には有効化を許容されないことが重要である。これは埋め込みコード内で制御され、適当な戻り値で示されることが好ましい。この方法により、内部キー管理において不確定な副作用が回避される。
サイドチャネルからの改ざんの可能性を除外するために、支払保証システムと値転送センターとの間のインターフェースは厳密であることが好ましい。
【０２１３】
値転送センター（郵便料金ポイント）と中央支払保証システムとの間のインターフェースの構造を図３に示す。
値転送センター（郵便料金ポイント）のＫｅｙＭａｎａｇｅｍｅｎｔ構成要素において生成されるキーが支払保証システムの暗号システムに配布可能であることにより、キー配布のためのインターフェースが中央支払保証システムに設けられる。
キーの配布成功と処理の後で支払保証システムがキーを放出可能であることにより、値転送センターによって支払保証システムにキー放出インターフェースが設けられる。
【０２１４】
両計画において主にＪａｖａ（登録商標）を用いているので、セッションビーンを用いる適用インターフェースの実現が推奨される。２つのシステムを分離するために、サービスはＪＮＤＩを用いて指定のサービスで調べるべきである。
【０２１５】
キーデータをＺｉｎＳセントラルシステムに受け入れるために必要な機能性がセッションビーンによって提供される。全体の通信は図４に示される。
データキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための処理手順が図４に示される。
【０２１６】
処理ルーチンＩｍｐｏｒｔＫｅｙによってデータキーセットがＺｉｎＳセントラルに転送される。
ＡＳＮ．１メッセージを使用することで、この処理ルーチンは受信メッセージを準備し、メッセージをデータベースに保存させる。処理ルーチンＩｍｐｏｒｔＫｅｙはそれからＣＷＭＳによるキーデータのＺｉｎＳローカルシステムへの配布を初期化する。
【０２１７】
データのデータベースへの受け入れシーケンスとそれに続くメッセージの配布は監視されるべきである。これによって受信されたデータが作業の前に安全性を保証される。この方法の利点は、エラーの領域のイベントをよりよく再構成でき、データの消失の場合には必要ならデータベースにアクセスできることである。
【０２１８】
この時点においてＡＳＮ．１フォーマットがサポートされているかが不明瞭なので、ＩｎｓｅｒｔＫｅｙＤａｔａ手法のパラメータはまだ指定されていない。しかし、詳細なメッセージを郵便料金ポイントにも送信可能とするためには２つのパラメータが装備されなければならないであろう。
【０２１９】
ＺｉｎＳセントラルにおいて、キー割り当てシステムの配布手法は下記の原因となる。
【０２２０】
１． ＺｉｎＳセントラルサーバー上でのキーメッセージのアーカイブ。
【０２２１】
２． ＶｉｂｒｉｓによるＣＷＭＳインターフェースによる、郵便料金ポイントから個別のメールセンターへのキーメッセージの配布。ＣＷＭＳの構造と利用はこのインターフェースの説明書に見られる。
【０２２２】
３． 個々のメールセンターへの配布と受け入れが完了した後に、付随する返送メッセージを生成する。
【０２２３】
データは値転送センター（郵便料金ポイント）からＡＳＮ．１フォーマットで伝達される。付随する応答も同様にＡＳＮ．１フォーマットと予想される。しかし、このフォーマットの代わりに他のフォーマットを用いることももちろん可能である。特定のフォーマットは適当なパーサーによって使用のために適用される。
ＡＳＮ．１の好ましいデータフォーマットは以下のものである。
【０２２４】
［移送キーの配布メッセージ］
ＴｒａｎｓｐｏｒｔＫｅｙＭｅｓｓａｇｅ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＭｓｇＴｙｐｅ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ｆｉｘ ‘ＫＴ’ ）
Ｖｅｒｓｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ）
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ）
ＳｉｇＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＳｉｇｎａｔｕｒｅＫｅｙ ｕｓｅｄ ｆｏｒ ＭＡＣ ）
ＴｒａｎｓＫｅｙＥｎｃｒｙｐｔ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＴｒａｎｓｐｏｒｔＫｅｙ ｗｒａｐｐｅｄ ｗｉｔｈ ＬＭＫ ）
ＭＡＣ ＯＣＴＥＴ ＳＴＲＩＮＧ （ ＭＡＣ ｏｖｅｒ ａｌｌ ｐｒｅｖｉｏｕｓ ｅｌｅｍｅｎｔｓ ）
【０２２５】
［データキーの配布メッセージ］
ＰｏｓｔａｇｅＫｅｙＭｅｓｓａｇｅ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＭｓｇＴｙｐｅ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ｆｉｘ ‘ＫＤ’ ）
Ｖｅｒｓｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ）
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ）
ＫｅｙＧｅｎｅｒａｔｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ａｓｃｅｎｄｉｎｇ ）
ＳｉｇＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＳｉｇｎａｔｕｒｅＫｅｙ ｕｓｅｄ ｆｏｒ ＭＡＣ）
ＴｒａｎｓＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＴｒａｎｓｐｏｒｔＫｅｙ ）
ＤａｔａＫｅｙＥｎｃｒｙｐｔｅｄ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＰｏｓｔａｇｅＫｅｙ ｗｒａｐｐｅｄ ｗｉｔｈ ＬＭＫ
ａｎｄ
ｅｎｃｒｙｐｔｅｄ ｗｉｔｈ ＴｒａｎｓｐｏｒｔＫｅｙ ）
ＭＡＣ ＯＣＴＥＴ ＳＴＲＩＮＧ （ ＭＡＣ ｏｖｅｒ ａｌｌ ｐｒｅｖｉｏｕｓ ｅｌｅｍｅｎｔｓ ）
｝
Ａｌｓｏ ｓｅｅ ｓｅｃｔｉｏｎ ２．４．６．
【０２２６】
［放出メッセージ］
ＫｅｙＥｘｃｈａｎｇｅＲｅｃｅｉｐｔ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ｒｅｃｅｉｖｅｄ ｋｅｙ ）
ＫｅｙＬａｂｅｌＨａｓｈ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＳＨＡ−１ ｈａｓｈ ｏｆ ＣＫＡ＿ＬＡＢＥＬ ｏｆ ｒｅｃｅｉｖｅｄ ｋｅｙ ）
Ｓｔａｔｅ ＢＯＯＬＥＡＮ， （ ＴＲＵＥ／ＦＡＬＳＥ ｔｏ ｅｎａｂｌｅ／ｄｉｓｍｉｓｓ ｋｅｙ ）
Ｍｅｓｓａｇｅ ＯＣＴＥＴ ＳＴＲＩＮＧ （ Ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ ｓｕｃｃｅｓｓ／ｆａｉｌｕｒｅ ）
｝
【０２２７】
データ構造は異なるセットアップを持つことができる。しかし、考慮される全ての情報の伝達を許容し、また小さいデータの送信の労力の説明となるので、提示された実施例におけるセットアップは特に有利である。特に、データはＣＷＭＳによって、好ましくは郵便サービス提供者のメールセンター内にある、局所支払保証システムへと伝達される。
【０２２８】
ＡＳＮ．１フォーマットが用いられる場合、データはまず内部キーメッセージに解析されなければならず、このドキュメント内に定義されるメッセージが直接使用される場合にはそれは不要となる。
【０２２９】
ＣＷＭＳによって受信されるデータパケットは、以前にこのドキュメント内に定義されたキーメッセージに対応する。これらのメッセージはそれから、最初にタイトル“データキーＫＤの属性”の上のデータ表に適合された後で、埋め込みコードのＶｅｒｉｆｙＭｓｇ手法に従属される。証明の後で、キーの受け入れが埋め込みコードによって開始され、あるいは適当なエラーメッセージが生成される。ＣＥ＿ＩｍｐｏｒｔＫｅｙ埋め込みコード手法における受け入れデータ構造の点において、キーメッセージとページ１２から１４を比較する。古いキーの消去と更新は前期の埋め込みコード手法によって自動的に行われ
【０２３０】
失効したキーを暗号ハードウェアから毎日除去するＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓが毎日呼び出される事が必要である。受け入れの間に、複製キーが消去され新しいものと置き換えられることがＣＡ＿ＩｍｐｏｒｔＫｅｙ手法によって保証される。
埋め込みコード手法はＪａｖａ（登録商標）クラス ＣｒｙｐｔｏＡｄａｐｔｅｒｓによってアプリケーションに結び付けられる。ＣｒｙｐｔｏＡｄａｐｔｅｒｓは、埋め込みコードおよび他のＰＫＣＳ＃１１手法が提示する（同様に指定された）全ての手法を提示する。
【０２３１】
ＪＮＩによって、Ｚａｘｕｓに提供されるＤＬＬを静的に連結したＤＬＬ（ＣｒｙｐｔｏＡｄａｐｔｅｒ．ＤＬＬ）が用いられる。静的連結によって安全性リスクがさらに最小化される。
【０２３２】
ＪＮＩインターフェースのＣ＋＋実装によって、個々の要求されたセッションのエラーの取り扱いが提供される。これに関連してＰＣＦＭデザインドキュメントの“マルチスレッディング”下のステージ３を参照。暗号ハードウェアをマルチスレッディングモードにおいて初期化し、作業者がＤＬＬに登録されエラー取り扱いが作業者に特異的に確立された結果として、ログインの後で個々の作業者が自身のセッションを得る（ｇｅｔＳｅｓｓｉｏｎ， Ｃ＿ＧｅｔＳｅｓｓｉｏｎ）ことで、作業者の構想が支援される。ＤＬＬの本流はログインによって移動され、Ｐｋｃｓ＃１１手法および埋め込み手法の実行のためのエラー取り扱いを同様に有する。
【０２３３】
実装の概観を図６に示す。キーリスト、および埋め込み手法によって提供されるコードは除去される。あるいは、構造のセットアップは同一であるように選択されなければならない。
【０２３４】
［ＤＬＬの接続］
好ましい封入と有利なエラー取り扱いの例を図７に示す。
キーリストが暗号ハードウェアの埋め込みコードに完全に保持されている場合は、キーリストの実装は必要ない。ＧｅｔＡｔｔｒｉｂｕｔｅ手法は単一の埋め込みＣＥ＿ＧｅｔＡｔｔｒｉｂｕｔｅ手法に削減される。同じ理由で、受け入れのための呼び出しおよび実装も、必要なデータの転送の後で埋め込みコードによって自動的に行われるので削減される。
【０２３５】
拡張されたエラー定数リストが埋め込みコード内に設けられる。
郵便料金ポイントからのキーメッセージがＺｉｎＳセントラルのデータベースに保存され、欠陥のある局所支払保証システムの後での置き換えを可能としている。第一にそのようなメッセージをデータベースに組み込むことが要求され、第二に管理情報が受信される。
その結果、以下のデータベース表が必要となる。
【０２３６】
【表１０】
【０２３７】
郵便料金ポイントに受信されることでキーデータがキーメッセージを保存し、局所支払保証システムの不良の場合、キーメッセージのアーカイブによって、アーカイブされたキーを受け入れることで不良の局所支払保証システムが残りの局所支払保証システムと調整される。保存の前にメッセージをＡＳＮ．１によって解析し局所システムに伝達する必要がある。分割された形態のデータレコードは保存様式として好ましい。これは、ＣＥ＿ＶｅｒｉｆｙＭｅｓｓａｇｅ埋め込み手法に用いられるデータブロックを説明する表に対応する。
【０２３８】
【表１１】
【０２３９】
このデータレコードは重要性を有する。これは第一にメールセンター、好ましくは郵便サービス提供者の郵送システムに統合された全てのメールセンターの局所支払保証システムから受信されたフィードバックを評価するとともに、配布手続きの間に時間が超過すれば常に、可能なエラー解析およびシステムオペレータへの警告を行う。
【０２４０】
同じ理由で、この表は管理情報処理を要する。適用可能であれば、これは入力ＳＮＩｔｅｍＮｏを用いて付随するＴｒａｎｓｐｏｒｔＫｅｙＤａｔａおよび個別の（８３）メールセンターのＴｒａｎｓｐｏｒｔＫｅｙＲｅｐｌａｙＭｅｓｓａｇｅの割り当てと評価を可能とする。
【０２４１】
【表１２】
【０２４２】
この表において、局所支払保証システムの個別の応答メッセージは郵便サービス提供者のメールセンター内に受け入れ手続きの機能としてアーカイブされる。
【図面の簡単な説明】
【０２４３】
【図１】本発明によるキーの配布の特に好ましい実施例を示す図。
【図２】本発明によるキー配布システムの適用例を示す図。
【図３】中央支払保証システム（ＺｉｎＳセントラルシステム）と値転送センター（郵便料金ポイント）との間のインターフェースの概略図。
【図４】データキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための手順を示す図。
【図５】付随する暗号を含む、中央支払保証システム（ＺｉｎＳセントラルシステム）から局所支払保証システムへのキーの配布の概略図。
【図６】ＤＬＬインターフェースの接続状態を示す概略図。
【図７（Ａ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【図７（Ｂ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【図７（Ｃ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【背景技術】
【０００１】
デジタル郵便証印を有する郵便物の作成手続きは公知である。
郵便物の差出人がデジタル郵便証印をより容易に作成できるように、例えば、ドイチェポストＡＧの用いる料金納付システムによって、顧客のシステムにおいて郵便証印を作成し、望ましいインターフェースを介してそれをプリンターから出力することが考えられる。
この形式のための方法の１つが、ドイツ予備出願公開ＤＥ １００ ２０ ４０２ Ａ１において開示されている。
【０００２】
この方法の不正な使用を避けるために、デジタル郵便証印は、例えば該郵便証印の作成を制御する顧客のシステムの識別に関する暗号情報を含むものとする。
【０００３】
この発明は、郵便証印の信頼性を素早く確実に証明可能とする方法の考案、という目的に基づいている。特に、該方法は大規模な、とりわけメールセンターまたは貨物センターでの証明手続きにおける利用に適していることが好ましい。
【発明の開示】
【０００４】
本発明によってこの目的は、信頼性証明の方法を、データキーを生成し中央データベース（ＺｉｎＳセントラルシステム）から局所支払保証システム（ＺｉｎＳローカル）へと伝達することによって達成される。これは生成された料金納付キーと郵便物に添付された郵便証印を用いてなされ、郵便証印に含まれる暗号情報を解読して該郵便証印の信頼性の証明に用いる。
【０００５】
該方法の安全性を高めるためには、局所支払保証システムがデータキーを受け入れ、受け入れの結果を中央データベース（ＺｉｎＳセントラルシステム）に伝達することが有利である。
【０００６】
この方法の特に好ましい実施形態においては、受け入れの結果はデータレコードとして伝達される。
該データレコードはキーを含むことが好ましい。該キーには様々な属性を持たせることができる。特に、対称キーまたは非対称キーとすることができる。意図して使用することによって、該キーは情報の解読および／または暗号化に用いることができる。その性質によって、該キーによって情報を伝達することもできる。例えば、キーには料金納付キー、そのキーの生成、および／またはその終了日付に関する情報を持たせることができる。
【０００７】
キーの均質な置換を保証するためには、中央データベース（ＺｉｎＳセントラルシステム）において受け入れの結果を確認し、それを値転送センター（郵便料金ポイント）に伝達することが有利である。
【０００８】
前記方法のこの実施形態によって、受け入れの結果の機能として、値転送センターでのさらなる処理手順の実行が可能となる。
【０００９】
この結果は様々な方法で確認される。しかし、結果をキーの解読によって確認することが特に有利である。
【００１０】
前記方法の好ましい実施形態は、まずデータキーをほぼ全ての局所支払保証システム（ＺｉｎＳローカル）へと受け入れ、値転送センターにおいて該データキーを新たな料金納付キーとして放出し、続いて新たな郵便証印の作成に用いることを特徴とする。
前記方法のこの実施形態によって、支払保証システムで先に行われたキーの置換の機能としての値転送センターでのキーの置換が可能となる。この方法によって、既に局所支払保証システムに存在していた新たなキーを用いてのみ郵便証印が作成されることが保証される。これによって、局所支払保証システムにより個々の生成された郵便証印の信頼性を証明可能であることが保証される。
【００１１】
前記方法の、この特に好ましい実施形態は、局所支払保証システムでのキーの置換の機能としての値転送センターでのキーの置換の制御を伴うが、これを少なくともいくつかの本発明に関する他の処理手順と組み合わせることが特に有利である。
特に、複数の特徴の組み合わせによって、キーの置換を素早く確実に行われることと、個々のキーの置換の実行が証明されることとが保証される。
【００１２】
キーの置換が行われる際に、新たなデータキーを値転送センター（郵便料金ポイント）から中央支払保証システムへと伝達することが有利である。
ここで、値転送センターにおいてデータキーを移送キー（ＫＴ）を用いて暗号化することが特に有利である。
ここで、移送キーをマスター移送キー（ＫＴＭ）を用いて暗号化することが実際的である。
【００１３】
データキーは値転送センター内で生成することが好ましい。これにはデータキーが値転送センターへの移送中に不正に変化されることを防止できるという利点がある。
データの安全性をさらに高めるためには、データキーをキー識別情報とともに提供することが有利である。
キー識別情報もまた暗号化した形式で伝達することが有利である。
【００１４】
個々の暗号化および／または解読の手順において正当なデータキーが用いられていることを保証するためには、データキーを生成カウンターとともに提供し、さらに／あるいは生成カウンターとともに伝達することが有利である。
【００１５】
無効なキーの使用を避けるためには、料金納付キーを先のデータキーの終了日とともに提供し、さらに／あるいは終了日とともに伝達することも有利である。
【００１６】
前述のデータキーは１つ以上の部分的な証明や、郵便証印の作成、および／または郵便証印に含まれる情報の解読に用いることができる。
【００１７】
郵便証印に含まれる暗号情報の解読を部分的な証明に含むことが特に有利である。
【００１８】
暗号情報の解読を証明手順に統合することで、郵便証印の信頼性を確認し、証明をリアルタイムで行うことが可能となる。
【００１９】
さらに、部分的な証明の１つが暗号情報の作成の日付と現在の日付との比較を含むことが有利である。郵便証印の作成の日付の、特に暗号化された形式での統合がデータの安全性を高める。それは、郵便証印の作成の日付と現在の日付との比較によって郵便証印の二重使用を防止できるからである。
【００２０】
証明速度のさらなる向上のためには、読み取りユニットと証明ユニットとが同期プロトコルによって情報を交換することが有利である。
本発明の別の同様な実施形態においては、読み取りユニットと証明ユニットとは非同期プロトコルによって互いに通信する。
【００２１】
ここで、読み取りユニットから証明ユニットへとデータ電文を送ることが特に有利である。
該データ電文は郵便証印の内容を含むことが好ましい。
【００２２】
本発明のさらなる利点、特徴および実際的な改良は、従属する請求項と図面に基づいて説明される以下の好ましい実施形態の提示とから見つけることができる。
【００２３】
図１は本発明によるキーの配布の特に好ましい実施例である。
図２は本発明によるキー配布システムの適用例である。
図３は 中央支払保証システム（ＺｉｎＳセントラルシステム）と値転送センター（郵便料金ポイント）との間のインターフェースの概略図である。
図４はデータキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための手順である。
図５は付随する暗号を含む、中央支払保証システム（ＺｉｎＳセントラルシステム）から局所支払保証システムへのキーの配布の概略図である。
図６はＤＬＬインターフェースの接続である。
図７はコンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図である。
【発明を実施するための最良の形態】
【００２４】
以下において本発明を、ＰＣ料金納付システムに関して説明する。ここで、支払保証のための手順は、郵便証印の作成に用いられるシステムから独立している。
個別の証明ステーション、特にメールセンターにおける前記の分散証明が特に好ましいが、集中証明も同様に可能である。
【００２５】
本発明の特に好ましい実施例においては、前記の個別の証明ステーションは局所支払保証システムとし、これらは好ましくはデータ接続によって中央支払保証システムに接続される。
前記の特に好ましい実施例において、中央支払保証システムはまた値転送センターにも接続される。
値転送センターの特に好ましい実施例を、以下において郵便料金ポイントと呼ぶ。中央支払保証システムの有利な実施例を、以下においてＺｉｎＳセントラルと呼ぶ。
【００２６】
値転送センターと支払保証システムとの間に実装される技術的インターフェースは、暗号キーの置換からなる。
【００２７】
転送センターと支払保証システムとの間で置換されるキーは、作成された郵便証印が偽造ではないことを保証する。これは、郵便証印を形成する二次元バーコードの一部を該キーによって暗号化することで達成される。能力による理由のために、選択されたキーは対称キーなので、転送センターから支払保証システムへと伝達される必要があり、そこから個別のメールセンターに配布される。
【００２８】
キーの高信頼保存は特別な暗号カードを用いることによって保証される。本発明は、これらのキーをこの特別なハードウェアを用いて管理する複数の適用例を包含する。これらのキーの生成から送出、配布、分散システムへの受け入れまでの全体の寿命は、プロセスパラメータの最適化のために用いられる。
【００２９】
キー配布のための特に好ましいシーケンスを図１に示す。
図１に、値転送センターと中央支払保証システムとの間での特に好ましいキー配布を示す。
郵便証印の作成に用いられる料金納付キーの置換のための最初の手順１において、まず新たな料金納付キーが生成される。
【００３０】
前記のキーは郵便証印の生成のための異なるやり方に用いることができるので、ここで料金納付キーという語を限定した意味で理解することはできない。
例えば、料金納付キーを直接郵便証印の作成のために用いることができる。
【００３１】
しかし、改ざんに対して特に安全性の高いシステムによって、多重に暗号化したデータ内容を有する郵便証印を作成することも、可能であり特に有利である。ここで該データ内容は好ましくは複数の操作によって形成され、１つ以上の場所で操作の結果を料金納付キーとともに郵便証印に組み込む。
例えば、ドイツ予備出願公開ＤＥ １００ ２０ ４０２ Ａ１に開示される形式の暗号文字列は料金納付キーに組み込まれる。
【００３２】
郵便証印の不正な作成に対し防御をさらに向上するために、料金納付キーのイベント特有の置換を行う。
提示された例において、料金納付キーは所定の間隔をあけて、例えば事前に定義できる時間間隔の満了の後で、新たに生成される。
【００３３】
しかし、料金納付キーの新たな生成を他のパラメータの機能として、例えば郵便物の課金額および／あるいは支払済みの郵便物に基づいて行うことも可能である。
【００３４】
原則の問題として、新たな料金納付キーの新たな生成はどこでも行える。しかし、データの安全性を高めるためには、新たな料金納付キーの伝達の労力を最小限とし、キーを値転送センター内で、あるいは値転送センターの領域内で生成することが有利である。
【００３５】
不正に対する方法の高レベルでの防御を保証するためには、郵便証印に含まれる情報を局所支払保証システムの領域内、例えばメールセンターまたは貨物センター内において料金納付キーに基づいて解読することが有利である。
これを保証するために、料金納付キーを値転送センターから中央支払保証システムへと伝達する。この伝達は自動化することが好ましい。
【００３６】
置換は支払保証システムのサーバー（ＺｉｎＳセントラルサーバー）を介して実施することが好ましい。値転送センター（郵便料金ポイント）を設定する必要はない。サーバーは値転送センター（ＺｉｎＳローカルシステム）とそれに属する暗号システムを認識する必要がないので、ＺｉｎＳセントラルサーバーのみが前記サーバーとして重要である。
【００３７】
好ましい対称型の料金納付キーの新たな生成の後で、後者は中央支払保証システムへと安全に伝達され（図１の手順２）、そこから局所支払保証システム内の暗号システムへと配布される（図１の手順３）。局所支払保証システム内から受け入れ操作の結果が返送され（図１の手順４）、キーの受け入れの成功が確認される。結果を中央システムでコンパイルし、確認し値転送センター（郵便料金ポイント）へと伝達する（図１の手順５）。
【００３８】
キーの全ての局所支払保証システム内の暗号システムへの受け入れが成功すると、値転送センター（郵便料金ポイント）において放出され、続いて新たな郵便料金額の生成に用いられる（図１の手順６）。
【００３９】
好ましい対称型の料金納付キーは、料金納付キーを用いて作成される郵便証印の偽造への安全性において不可欠な部分であり、該郵便証印は例えば二次元バーコードの形式とする。したがって、これらのキーの置換は強力な暗号法によって安全を確保する必要がある。これを保証するためには、以下の点を支持することが特に重要である。
・内容の機密性：伝達の間に、第三者が伝達されるキーを読み出すことが可能であってはならない。さらに、キーが安全に保存され、第三者による読み出しが不可能であることも保証されなければならない。後者の機能性はウェブセントリー（ＷｅｂＳｅｎｔｒｙ）の暗号カードによって保証される。
・内容の保全性：第三者がキーの一部を偽造することが可能であってはならない。
・認証：双方の通信パートナーは差出人／受取人の認証が正しいことを確認しなければならない。受取人の見地からは、これはキーが郵便料金ポイントにおいて生成されたということを意味する。差出人の見地からは、正当なＺｉｎＳローカル暗号システムのみがキーを受信できることが保証されなければならない。
【００４０】
提示された対称型の方法において、双方の通信パートナーは同一のキーＫＴを持つ。値転送センター（郵便料金ポイント）はキーＫＴを用いて、伝達されるデータキーＫＤを暗号化し、それからデータキーＫＤを支払保証システム（ＺｉｎＳセントラルシステム）のサーバーへと転送する。
【００４１】
それからこのキーをさらに中央支払保証システムから局所支払保証システムのＺｉｎＳローカル暗号システムへと移送する。これらのシステムもキーＫＴにアクセスし、それによってキーＫＤを再び解読できる。キーＫＤを移送の間に安全に防御するためにキーＫＴを用いるので、キーＫＴも以下において移送キーと呼ぶ。
【００４２】
全ての局所支払保証システムが同じデータを受信するので、個々の局所暗号サーバーと値転送センター（郵便料金ポイント）との間で別々の移送キーＫＴを定義する必要がない。しかし、安全性の理由から、このキーＫＴはデータキーＫＤのように一定の間隔で更新するべきである。しかし、キーＫＤではあまり多くのテキストを暗号化しないので、交換の間隔は長くすることができる。１年または２年の交換間隔が、ここでは特に有利である。
【００４３】
この方法の不可欠な構成要素は移送キーＫＴの置換であり、これは安全性の理由から、データキーＫＤの置換と同じチャンネルで行うべきではない。この置換は手動では行わない。この手続きは複数の局所支払保証システムについて一定間隔で行わなければならないので、移送キーの置換も自動化できるように、ここで別の手法を提供しなければならない。
【００４４】
この目的のために、ＡＮＳＩ規格Ｘ９．１７（金融サービスのための対称手法に基づいたキー管理）において、マスター移送キー（以下、ＫＴＭと呼称）と呼ばれる別のキーレベルが定義されている。このキーは特別な安全性警戒の元で暗号カードにインストールしなければならず、また拡大した間隔において置換しなければならない。ここで、全てのシステムに同じＫＴＭがインストールされる。それからこのキーで移送キーＫＴを暗号化し、その後キーＫＴを同じチャンネルによって自動化された様式で配布し、受け入れを行う。該配布はデータキーの配布と同様に行われる。個別のシステムまたはその暗号カードの初期化については以下の節で詳述する。
【００４５】
メッセージの保全性と差出人（郵便料金ポイント）の認証を保証するために、個別のキーメッセージにマトリクスコード（ＭＡＣ）が形成される。ＭＡＣの生成のために、ＫＴＭと同様に暗号カードの初期化の間に受け入れられる署名キーＫＳが必要となる。データキーメッセージの署名は、その後でこのキーＫＳによってなされる。ドイチェポストのイントラネット内での伝達の間におけるメッセージの機密性は、強い暗号手法を用いることでこのように確保される。メッセージの暗号化と解読の特に好ましい手法はトリプルＤＥＳ（キー長１６８ビット）である。ハッシュ値はＳＨＡ−１アルゴリズムによって計算することが好ましい。
【００４６】
郵便料金ポイントと支払保証システムの暗号システムに存在する正当性の様々な周期を、データキーの配布と保存のために考慮しなければならない。最大２つのキーＫＤが所定の時間において郵便料金ポイントで利用可能でなければならない。つまり、１つのキーは現在正当であり、新たに生成された郵便料金額を伴うもう１つのキーは暗号化される（ＫＤｎｅｗ）。
【００４７】
該キー（ＫＤｎｅｗ）による既存のキーの操作の‘置換’モードにおいて、新たなキーが支払保証システムの暗号システムに伝達される。このキーを全ての局所支払保証システムの暗号システムに受け入れ成功してから、ＺｉｎＳセントラルシステムの放出メッセージが生成され、この時点において、ＫＤｎｅｗが郵便料金ポイントの新たな郵便料金額の暗号化に用いられる。この時点において、古いＫＤは郵便料金ポイントから消去すべきであり、またこれ以上新たな郵便料金額の生成に用いられるべきではない。
【００４８】
局所支払保証システムの暗号システムでは状況は異なる。ダウンロードされた郵便料金額は事前に定義できる時間の周期、例えば３ヶ月にわたって郵便証印の作成に使用でき、複数のキーＫＤが郵便証印の証明に利用可能でなければならない。
【００４９】
さらに、キーの配布の際には、暗号システムに受け入れられず郵便料金ポイントにおいて有効化できなかったキーに何があったのかも考慮すべきである。これらのキーを他の暗号システムに受け入れさせることが可能であり、原則の問題として、さらなる証明の間についても考慮すべきである。
【００５０】
ここで、キーの明瞭な更新と可能な最も単純なシステムのメンテナンスを許容する一様な状態に達するためには、以下のキー配布の手法の実行方法の形式が特に好ましい。
（ａ）データキーは暗号化された形式で、確定したキーＩＤ（キー位相表示）、不確定な生成カウンター、および正当先行データキーとともに伝達される。
（ｂ）値転送センター（郵便料金ポイント）からのデータキーの個々の伝達は、中央支払保証システムで確認メッセージによって確認されるべきである。
（ｃ）確認が正だった場合は、全ての局所支払保証システムへのデータキーの受け入れは成功していて、顧客はキーを利用してＰＣ料金納付を行うことができる。
この場合、生成カウンターは続くキーの伝達のたびに増加する。
（ｄ）確認が負だった場合は、全ての局所支払保証システムへのデータキーの受け入れは成功しておらず、値転送センターは顧客のシステムに郵便証印を作成させるべきではない。でなければ正当な郵便物が多量に転用される危険があるためである。
この場合、生成カウンターは続くキーの伝達のたびに増加しない。すなわち、先の伝達の値のままとなる。
（ｅ）確認がない場合は、その間、値転送センター（郵便料金ポイント）はこれ以上の中央支払保証システム（ＺｉｎＳセントラル）へのキー伝達が不可能となる。（このような試行は当然、支払保証システムによって却下されるが、値転送センター内で阻止すべきである）
（ｆ）延長された時間周期にわたって支払保証システムによる確認がない場合（タイムアウト超過）、値転送センター（郵便料金ポイント）はその直接あるいは間接のユーザーインターフェースによって警報を出すことができる。
（ｇ）暗号カードがデータキーを受信したらすぐに、最前の伝達としての同じ生成カウンター値を持つデータキー全てを消去する。これによって、エラーによる伝達が多数の場合、かつて暗号カードへの読み込みに成功したキーのみが消去される。トランザクションの安全なキー伝達が許容される。
（ｈ）局所支払保証システムの暗号カードにおいて、ルーチンが繰り返し、好ましくは定期的に、特には日毎に呼び出され、それは既に必要でなくなったデータキーを消去する。続くデータキーに関してＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性に保存された終了日付が現在のシステムデータより小さい際に、データキーは（（ｇ）や他の有利な実施例において）消去される。
（ｉ）先のキーの終了日付になると、（できるだけ短い）猶予期間が計画されるべきである。それは、局所支払保証システムの領域で確認されると、失効した郵便料金額とともに作成された郵便証印が、その正当性が終了した後でまださらに２日間正当だと認識されるためである。さらに、新たなデータキーの生成と放出のタイムラグも考慮しなければならない。
【００５１】
図２において現在のキーの管理の適用領域とその支払保証の領域における利用の概観が示される。さらに、適用の好ましい領域が提示される。
以下において適用例を詳述する。
【００５２】
続いて、前述のキー管理手法の詳細を提示する。
前述の適用は、暗号カードを用いる例によって提示する。
【００５３】
まず、値転送センターの領域において暗号カードを初期化する方法を提示する。
・製造業者の範囲においては、カードのインストールと設定、カードのファームウェアのアップロードはまだなされていない。ファームウェアの機能性は埋め込まれたコード（著作権のあるソフトウェアルーチン）によって拡張される。安全性の理由から、ＰＫＣＳ＃１１（公開鍵暗号基準）によるキールーチン（生成、消去等）はユーザーによって阻止されるべきである。これにより、カードにおいてより高いキーの安全性が保証される。
・（複数の暗号カードを有する）クラスターの定義。
・局所マスターキーＬＭＫの生成と保存。ＬＭＫは３つ以上の成分に配布されるべきであり、成分の２つは暗号サーバーカードの再形成または初期化に特に有利である。個々の成分はスマートカードにＰＩＮ防御によって書き込まれることが好ましく、そして安全性管理者はスマートカードを受け取る。なお、バックアップのスマートカードも作成すべきである。その後、ＬＭＫを前記のマスター移送キーＫＴＭとして用いる。
・ユーザー管理：デフォルトの安全性管理者の消去と、（スマートカードに基づく）必要な認証規則を含む安全性管理者の定義。
・初期の署名キーＫＳの生成、ＫＴＭによる暗号化（ラップ）およびファイルとしての保存。このファイルのディスケットへの後のコピーは可能とすべきである（ファイル／ディスケットへのアクセスは安全性管理者にのみ可能とすべきである）。
・最初の移送キーＫＴの生成、付随するキーメッセージの創作、およびメッセージのファイルへの保存とその後での該ファイルのディスケットへのコピー（アクセスは安全性管理者にのみ可能とすべきである）。
【００５４】
［移送マスターキーの生成］
新たな移送マスターキー（ＫＴＭ）は以下に述べる様式で生成することが望ましい。付随する確認カードの局所マスターキー（ＬＭＫ）をＫＴＭとして用いる。安全性の理由から、ＬＭＫは３つ以上の成分に分割されるべきであり、成分の２つ以上は再受け入れに必要である。
【００５５】
個別の成分をスマートカードに保存し、個々の安全性管理者はスマートカードを受け取り個々のＰＩＮによりその安全性を確保する。ＰＩＮの機密を維持しスマートカードを安全な場所に保存することで、権限のない者がそれらにアクセス可能となることを防ぐ。
【００５６】
移送マスターキーの実装のために、２つ以上のＬＭＫ成分（２つの異なる認可カードに関する）が存在することが好ましく、これによって二重制御原則の自動的な実装が実行される。
【００５７】
ＫＴＭはトリプルＤＥＳキーでなければならない。キーのＩＤ属性は型式識別および確定した数からなる。
型式識別：ＫＴ
確定した数：０１から９９
長さ：固定４バイトがＣＫ＿ＣＨＡＲ［ ］として保管される。
【００５８】
原則の問題として、認可された者のみがキーを置換可能であることを保証するために、様々な安全性機構が適している。しかし、以下で述べる署名キーを用いる実施例は、改竄操作に対する特に高い安全性をもたらすので、特に有利である。
【００５９】
署名キーはキーメッセージの保全性を保証する。これはまた、キーメッセージの差出人が郵便料金ポイントであるかどうかを確認するのにも利用できる。署名キーの生成は、スマートカードで登録された安全性管理者にのみ可能とすべきである。これは、ＴＲＵＥに設定された‘感受性’とＦＡＬＳＥに設定された‘抽出’の安全性属性を有し、キー平文がカード外部で発見されることを防ぐＴＤＥＳキーであるべきである。キーのＩＤ属性は型式識別および確定した数からなる。
型式識別：ＫＳ
確定した数：０１から９９
長さ：固定４バイトがＣＫ＿ＣＨＡＲ［ ］としてファイルされる。
【００６０】
キーは送出のためにＫＴＭでラップする必要があり、それからディスケット上にファイルとして保存される。ディスケットは安全な場所に置かねばならず、暗号カードの初期化に用いる。キーファイルの保全性は、好ましくはラップに用いるカードに保存される、処理ルーチンによって保証される。
【００６１】
移送キーＫＳの好ましい属性は以下の表に編集される。
【００６２】
【表１】
【００６３】
ＬＡＢＥＬ属性の乱数は暗号サーバーカードへの受け入れ成功の確認に用いられる。ハッシュ値（例えばＳＨＡ−１による）はこの乱数のために形成され、受け入れ成功の確認と移送キーの放出のために用いられる。
【００６４】
ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲとしてファイルされる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００６５】
署名キーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化され、ＬＭＫのようにサイト上のハードウェアにアップロードされる。
【００６６】
移送キーの生成について以下で述べる。
この適用例においては、付随するキーメッセージを含む移送キーが生成される。
移送キーおよび／または付随するキーメッセージは安全性管理者によってのみ初期化可能なようにキー生成モジュールを設定することが好ましい。置換間隔は１年または２年とすべきである。
【００６７】
次に、移送キーは、以下の属性設定を備えるＴＤＥＳキーである。
【００６８】
【表２】
【００６９】
ＬＡＢＥＬ属性の乱数は暗号サーバーカードへの受け入れ成功の確認に用いられる。ハッシュ値（例えばＳＨＡ−１による）はこの乱数のために形成され、受け入れ成功の確認と移送キーの放出のために用いられる。
【００７０】
ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲとしてファイルされる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００７１】
移送キーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化され、値転送センターから中央支払保証システムへの伝達のために以下の構造を持つメッセージが形成される。
【００７２】
【表３】
【００７３】
さらなる配布に続いて、この移送キーメッセージはＺｉｎＳセントラルサーバーへと転送される。インターフェースはセッションビーンによって実現され、このサービスは指定のサービス（Ｊａｖａ Ｎａｍｉｎｇ ａｎｄ Ｄｉｒｅｃｔｏｒｙ Ｉｎｔｅｒｆａｃｅ−ＪＮＤＩ）によって調べられる。移送の手法は前記のデータブロックを要求すべきである。
【００７４】
さらに、メッセージを郵便料金ポイントにファイルとして保存し、安全性管理者はこれを後で、安全な場所に保存される１つ以上のディスケットに保存することができる。ディスケットはそれから暗号サーバーカードの初期化に用いられる。
【００７５】
移送キーの放出の好ましい実施例を以下に説明する。
値転送センターは移送キーＫＴを放出可能に設定される。移送キーＫＴの放出のために、全ての局所支払保証システム（ＺｉｎＳ暗号システム）への配布と受け入れが成功した移送キーを中央値転送センターから放出可能なインターフェースがある。放出によってのみ、付随する移送キーが続いてデータキー（ＫＤ）の暗号化に用いられる。
【００７６】
前記インターフェースはセッションビーンとして実現される。このサービスは指定のサービスによって調べられる。
放出手続きのデータ構造は以下のパラメータを有することが好ましい。
【００７７】
【表４】
【００７８】
ＰＰキー管理システムに対する支払保証システムのキー割り当てシステム（ＺｉｎＳキー管理システム）の認証はパラメータ２で行われる。これはＳＨＡ−１の手法を用いて移送キーのＬＡＢＥＬ属性から形成されるハッシュ値である。ＬＡＢＥＬ属性は移送キーの生成の際に乱数で埋められる。移送キーとその全ての属性は伝達の間に暗号化されるので、ＺｉｎＳ暗号サーバーのみが正しいハッシュ値を計算できる。
【００７９】
伝達されたハッシュ値がＬＡＢＥＬ属性のために計算されたＫＴのハッシュ値と同一の場合、該ハッシュ値は郵便料金ポイントウェブセントリーモジュールに位置され、伝達された処理ステータスが真の場合、移送キーは有効化される。これは、続いてデータキーメッセージが移送キーを用いて暗号化されることを意味する。
【００８０】
処理が誤っている（伝達されたステータスが偽である）場合には、この適用例の変形が存在する。この場合、このキー生成とキー配布のためのステータスがプロトコル処理され、付随する移送キーはこれによって消去される。
【００８１】
新たなデータキーの生成の好ましい例を以下に示す。
この適用例においては、付随するキーメッセージを含むデータキーが生成される。キー割り当てシステムは、この動作が安全性管理者によってのみ初期化可能なように設定される。これは３ヶ月毎に行われるべきである。中央支払保証システム（ＺｉｎＳセントラルシステム）からフィードバック（放出またはエラー）が受信されておらず、データキーＫＤが流通している場合、フィードバックが受信されるまで新たなＫＤの生成は阻止される。
【００８２】
データキー（ＫＤ）は特定のマトリクスコード内容の暗号化を行い、また支払いが郵便サービス提供者になされていない場合は正当な郵便証印を作成できないことを保証する。このデータキーによってＺｉｎＳ暗号サーバーにおいてデジタル郵便証印が証明される。データキーは、ＰＫＣＳ＃１１機能Ｃ＿ＧｅｎｅｒａｔｅＫｅｙを用いて生成され以下の属性を持つＴＤＥＳキーと同様である。
【００８３】
【表５】
【００８４】
ＣＫＡ＿ＩＤ属性の値と生成カウンターはシステムに規定される。ＣＫＳ＿ＩＤは上方へ１ずつカウントされるが、生成カウンターはキーの放出が成功したときのみ増加する。ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲ ［ ］として埋められる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００８５】
ＬＡＢＥＬ属性の乱数によって暗号サーバーカードへの受け入れの成功が確認される。この乱数のためにハッシュ値が（ＳＨＡ−１によって）形成され、移送キーの受け入れの成功の確認と放出に用いられる。
【００８６】
データキーの置換のためのメッセージの生成はいくらか複雑で、以下のシーケンスを含む。
【００８７】
１． データキーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化される。これには、キーの全ての属性（特にＣＫＡ＿ＥＸＴＲＡＣＴＡＢＬＥ＝ｆａｌｓｅ）が同時に暗号化され、解読の際に正しく再設定されるという利点がある。この暗号化されたバイトシーケンスを用いて、以下の構造を持つ仮のメッセージが形成される。
【００８８】
【表６】
【００８９】
２． 次に、仮のメッセージは有効な移送キーＫＴによって、ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構を用いて暗号化される（初期化ベクターはゼロで埋める）。
【００９０】
３． 配布されるメッセージを形成し、それは以下の構造を有するものとする。
【００９１】
【表７】
【００９２】
４． その後、データキーメッセージをＺｉｎＳセントラルサーバーへのさらなる配布のために転送する。さらに、安全性管理者によって１つ以上のディスケットに保存し、それを安全な場所に保管して、新たなＺｉｎＳ暗号カードの初期化に使用できるようにする。
【００９３】
メッセージ内容の二重暗号化の利点は、暗号化の少ないテキストはインターネット経由でＫＴＭに伝達しなければならず、したがってこのキーの暗号解析がはるかに困難になる、ということである。
【００９４】
データキーＫＤの放出のために、インターフェースとプロトコル機構を設け、データキーの放出をプロトコル処理する。データキーの局所支払保証システムへの配布と受け入れの成功の後にのみデータキーを放出するように中央支払保証システムを設定することが好ましい。この放出によってのみ、付随するデータキーは続いて暗号文字列の暗号化に用いられ、郵便証印に組み込まれ付随キー識別情報ＫｅｙＩＤを郵便料金額の識別情報（ＰｏｓｔａｇｅＩＤ）の中で暗号化する。
【００９５】
インターフェースは中央支払保証システム（ＺｉｎＳセントラル）と局所支払保証システム（ＺｉｎＳローカル）との間のＣＷＭＳ（コンピューター作業管理システム）によって実現される。値転送センター（郵便料金ポイント）ＰＰは適切なビーンから情報を受信する。放出手続きのためのデータ構造は以下の内容を有する。
【００９６】
【表８】
【００９７】
値転送センターＰＰのキー割り当てシステムに対する、支払保証システムのキー割り当てシステムの認証は、パラメータ２によって行われる。これはＳＨＡ−１の手法を用いて移送キーのＬＡＢＥＬ属性から形成されるハッシュ値である。ＬＡＢＥＬ属性は移送キーの生成の際に乱数で埋められる。データキーとその全ての属性は伝達の間に暗号化されるので、支払保証システムの暗号サーバーのみが正しいハッシュ値を計算できる。
【００９８】
伝達されたハッシュ値がＬＡＢＥＬ属性のために計算されたＫＤのハッシュ値と同一の場合、該ハッシュ値は郵便料金ポイントウェブセントリーモジュールに位置され、伝達された処理ステータスが真の場合、移送キーは有効化される。これは、続いて郵便証印／郵便料金額のための暗号文字列がこのデータキーを用いて暗号化されることを意味する。データキーが有効化されると、署名キーの生成カウンターが１つずつ増加する。
【００９９】
処理が誤っている（伝達されたステータスが偽である）場合、この適用例の変形が存在する。この場合、このキー生成とキー配布のためのステータスがプロトコル処理され、付随する移送キーはカードから消去される。この場合、署名キーの生成カウンターが１つずつ増加することはない。
【０１００】
キー割り当てシステムは実行されたキー生成を保存するステータスメモリーを有することが好ましい。実行されたキー生成のついて中央支払保証システム（ＺｉｎＳセントラルシステム）からのフィードバックが受信されていないと、ステータスが開いて表示される。フィードバックと配布が成功すると、有効化されているとしてキーが指定される。エラーの場合は、伝達されたステータスメッセージが表示される。エラーあるいは放出メッセージの不在が延長された場合、エラー調査ルーチンが呼び出される。
【０１０１】
キーをアーカイブすることが有利である。値転送センターの領域における好ましいキーのアーカイブについて以下で説明する。キーの安全性を保証するために、安全性管理者は全てのキー（ＫＴＭを除く）をＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化して返送するアーカイブ機能を開始することができる。これらのキーはデータベースまたは安全ファイルシステム領域に安全に保存されるべきである。
アーカイブの成功の後で、初期正当性日付を６ヶ月以上過ぎて既に有効でない全てのキーが消去される。
【０１０２】
特に値転送センターＰＰの領域において、キーは復旧され、アーカイブされたキーデータは解読され（ラップを解かれ）カードに保存される。ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構が再び用いられる。
キーが解読された後で、既にカードに存在していた同一のキー識別情報ＫｅｙＩＤを有するキーは消去される。
【０１０３】
ウェブセントリーカードの特別な安全性手段と複数のスマートカードへの配布によって、マスター移送キーＫＴＭは漏洩に対し確実に安全性を保証される。
にもかかわらずマスター移送キーの置換がなされる場合は、“暗号カード”（ＰＰ）の初期化を含む適用例と同様に、新たなＫＴＭと新たな署名キー、移送キーおよびデータキーを生成しなければならない。
先のＫＴＭはいわゆる“潜在ＬＭＫ”としてカードに残され、安全性管理者によって適当に消去されなければならない。
【０１０４】
キー割り当てシステムの好ましい適用例を以下で説明する。提示は支払保証システムの全ての領域に適用される。これは特に個別の構成要素が、好ましくは局所支払保証システムまたは中央支払保証システムの領域に実装される場合に有利である。しかし、他の支払保証システムにおける使用も同様に可能である。
【０１０５】
第１の適用例は支払保証システムの領域における暗号カードの初期化である。
暗号カードの初期化のために以下の基本的な設定が用いられ、機能性の大半は管理ツール（ウェブセントリーマネージャー（ＷｅｂＳｅｎｔｒｙＭａｎａｇｅｒ））で管理できる。
・製造業者が既に行っていない範囲での、暗号カードのインストールと設定、カードファームウェアのアップロード。ファームウェアは埋め込まれたコード（著作権のあるソフトウェアルーチン）を有する。（後の機能性はウェブセントリーマネージャーに統合される）
・クラスターの定義づけ（複数の暗号カードを用いる）（ウェブセントリーマネージャー）
・移送マスターキー（ＫＴＭ）の受け入れ、分離適用例を参照（機能性はウェブセントリーマネージャーによって提供される）
・ユーザー管理：デフォルトの安全性管理者の消去と、（スマートカードに基づく）必要な認証規則を含む安全性管理者の定義
あらかじめ定義されたＰＩＮによって認可される、２つの“通常”ユーザーの生成（１つはキー証明のため、もう１つはキー受け入れのため）
ユーザー管理の機能性は同様にウェブセントリーマネージャーによって提供される。
・署名キー（ＫＳ）の受け入れ：分離適用例を参照
・移送キー（ＫＴ）の受け入れ：分離適用例を参照
・随意のデータキー（ＫＤ）の同様な受け入れ：（同様にその適用例を参照）すでに生成された範囲内
【０１０６】
キーは以上で定義したシーケンスにおいて受け入れられなければならない。カードは中央において初期化可能で、完全な暗号システムコンピューターを初期化し、その後送らなければならない。これはウェブセントリーカードがＰＣＩスロットから引き抜かれるとすぐに内部の記憶を消去するからである。
【０１０７】
暗号システムに対しスマートカードリーダーと関連したスマートカードで局所的に識別された２人以上の安全性管理者によってのみ、移送マスターキーを受け入れることが可能であることが好ましい。キーＫＴＭの重要性のために、このキーは二重制御原理を用いてのみカードに受け入れ可能とする。これは適用例“移送マスターキー”において生成された２つ以上のＰＩＮ防御スマートカードが受け入れに必要であることを意味する。
【０１０８】
マスター移送キーＫＴＭは双方のスマートカードを用いてのみ読み込み可能で、キーの使用はＰＩＮ防御されているため、このキーは二重制御原理を用いてのみカードにインストール可能であることが保証される。これによって違法なキーに対し非常に高い水準の防御を提供できる。
【０１０９】
この機能性は管理ツール、ウェブセントリーマネージャーによって提供される。この管理ツールによって、いわゆる局所マスターキー（ＬＭＫ、この構想において述べられたＫＴＭに対応）をスマートカードから読み出し、カードの安全な保存領域に保存することが可能となる。
【０１１０】
ＬＭＫを３つのスマートカードに配布することが特に有利であり、ＬＭＫを暗号ハードウェアに受け入れるために全ての３つの部分が必要である。この場合、マスター移送キーＫＴＭの受け入れのために３人の安全性管理者が必要である。
【０１１１】
署名キーはキーメッセージの保全性を保証する。これはまたキーの受け入れの前に、キーメッセージの送信者が値転送センター（郵便料金ポイント）であるかどうかを決定することにも使用できる。署名キーは異なる方法で生成することが可能で、ここで提示する例は特に有利なものである。付随キーメッセージは管理者によってディスケット上に保存され、この適用例では、初期化される支払保証システムの暗号カードに受け入れられる。
【０１１２】
キーの受け入れのために、ディスケット上に保存されたキーメッセージをマスター移送キーＫＴＭ（ＰＫＣＳ＃１１機能Ｃ＿Ｕｎｗｒａｐ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて解読する。キーメッセージの保全性はこのルーチンによって自動的に確認される。このキーＩＤを持つキーが既に存在している場合は、続いて削除される。
【０１１３】
移送キーメッセージのさらなる移送のために、中央支払保証システムのサーバーにインターフェースが設けられ、これによって配布とそれに続く個別の支払保証システムの暗号システムへの受け入れを初期化することができる。
【０１１４】
インターフェースはＲＭＩサービスによって実現される。このサービスは指定のサービス（ＪＮＤＩ）によって調べられる。配布はＣＷＭＳ（コンピューター作業管理システム）によって、Ｐ／Ｎリストの配布を用いてなされる。
【０１１５】
新たな配布ジョブが創作されると、キーメッセージは全ての現在登録されている暗号システムに転送され、個々の場合にプロトコルの入力が書き込まれる。暗号システムの管理は支払保証システムの適用例によってなされる。
【０１１６】
新たなキーメッセージの受信は個別の暗合システムにおいて受け入れ制御装置によって一定の間隔でなされる（配布機構の機能として）。新たなメッセージが受信されると、適用例“移送キーの受け入れ”が自動的に実行される。この動作の戻り値を確認する。負のフィードバックを受信した場合は、受け入れの試行を３回まで繰り返す。
【０１１７】
３回の試行の後でまだ受け入れが不可能な場合は、失敗に関するプロトコルメッセージをＺｉｎＳセントラルシステムに送信する（再び移転機構の機能として）。受け入れが成功した場合は、正のプロトコルメッセージが発行される。
プロトコルメッセージは適用例“プロトコルキー処理”によって中央で処理される。移送キーの放出も同様に開始される。
【０１１８】
移送キーの受け入れはサイト上の暗号システムを初期化する安全性管理者によって実行されるか、あるいはこの受け入れは受け入れ制御装置が新たな移送キーメッセージを受信した際に受け入れ制御装置によって自動的に開始されるものとする。キーは以下の処理手順によって受け入れられることが好ましい。
【０１１９】
１． カードへの登録はキー受け入れユーザーに属するＩＤとＰＩＮによってなされる。
【０１２０】
２． ハッシュ値はＳＨＡ−１手法を用いて移送キーのフィールド１から５へと形成される。
【０１２１】
３． 署名キーがフィールド４に表示されるキーＩＤを有していることを確認する。
【０１２２】
４． このキーは上記２で形成されたハッシュ値の暗号化に用いられ（ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）、フィールド６と比較される。これらの２つの値が合致すると、保全性が保証され、メッセージがＰＣ料金納付システムによって創作されたことが保証される。
【０１２３】
５． メッセージのフィールド５の内容はＫＴＭ（Ｃ＿ＵｎｗｒａｐＫｅｙ手法、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）によって解読される。結果、適当な移送キーオブジェクトが自動的に生成されカードに保存される。なお、該機構は再び暗黙のうちにキーの保全性と差出人の正確さを確認する。
【０１２４】
６． カードに同一のキーＩＤを持つキーが既に存在する場合、それは消去される。
【０１２５】
７． 新たに受け入れられたキーのＬＡＢＥＬ属性に、ハッシュ値がＳＨＡ−１手法を用いて形成され、これはキーＩＤおよび戻り値としての正のメッセージとともに返送される。
【０１２６】
８． ユーザーのセッションを終了する。
【０１２７】
９． プロトコルメッセージを戻り値から創作し、ＺｉｎＳセントラルシステムに送信する。
【０１２８】
１０． このキーＩＤのために保存されている失敗した試行がリセットされる。
【０１２９】
この適用例の変形は、ルーチンの１つまたはＭＡＣの確認の失敗である。この場合、さらなる処理は打ち切られ、キーＩＤ、エラーコードおよびエラーメッセージを含む戻り値が返送される。キーＩＤについて、保存されている失敗した試行の数が１つずつ増加する。この数が３に達すると、最も新しく転送された戻り値からプロトコルメッセージが創作され、中央支払保証システムに送信される。
【０１３０】
手動での初期化の場合、さらに受け入れの結果が安全性管理者のモニターに表示される。
手順２から７をカードソフトウェアにおいて直接実行することが好ましい（埋め込みコード）。これによって性能および違法に対する安全性が向上する。
【０１３１】
データキーメッセージのさらなる移送のために、中央支払保証システムのサーバーに、局所支払保証システムの個別の暗号システムへのデータキーの配布とそれに続く受け入れのための新たなインターフェースを設ける。
インターフェースはセッションビーンとして実現され、このサービスは指定のサービス（Ｊａｖａ Ｎａｍｉｎｇ ａｎｄ Ｄｉｒｅｃｔｏｒｙ Ｉｎｔｅｒｆａｃｅ−ＪＮＤＩ）によって調べられる。
【０１３２】
配布はＣＷＭＳ（コンピューター作業管理システム）によって、Ｐ／Ｎリストの配布を用いてなされる。
【０１３３】
新たな配布ジョブが創作されると、キーメッセージは全ての現在登録されている暗号システムに転送され、個々の場合にプロトコルの入力が書き込まれる。暗号システムの管理は支払保証システムの適用例によってなされる。値転送センターＰＰにおいてフィードバックが受信されておらず、データキーの配布ジョブが既に循環している場合は、フィードバックの時点までさらなるデータキーの配布ジョブの受容が拒否される。
【０１３４】
新たなキーメッセージの受信は個別の暗合システムにおいて受け入れ制御装置によって一定の間隔でなされる（配布機構の機能として）。新たなメッセージが受信されると、適用例“移送キーの受け入れ”が自動的に実行される。この動作の戻り値を確認する。負のフィードバックを受信した場合は、受け入れの試行を３回まで繰り返す。
【０１３５】
３回の試行の後でまだ受け入れが不可能な場合は、失敗に関するプロトコルメッセージをＺｉｎＳセントラルシステムに送信する（再び移転機構の機能として）。受け入れが成功した場合は、正のプロトコルメッセージが発行される。
プロトコルメッセージは適用例“プロトコルキー処理”によって中央で処理される。移送キーの放出もこの適用例によって開始される。
【０１３６】
移送キーの受け入れはサイト上の暗号システムを初期化する安全性管理者によって実行されるか、あるいはこの受け入れは受け入れ制御装置が新たな移送キーメッセージを受信した際に受け入れ制御装置によって自動的に開始されるものとする。
【０１３７】
データキーメッセージの特徴を考慮して、キーは移送キーの受け入れと同様にして受け入れられる。
【０１３８】
１． カードへの登録はキー受け入れユーザーに属するＩＤとＰＩＮによってなされる。
【０１３９】
２． ハッシュ値はＳＨＡ−１手法を用いて移送キーのフィールド１から７へと形成される。
【０１４０】
３． 署名キーはフィールド５に表示されるキーＩＤを有することを確認される。
【０１４１】
４． このキーは上記２で形成されたハッシュ値の暗号化に用いられ（ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）、フィールド８と比較される。これらの２つの値が合致すると、保全性が保証され、メッセージがＰＣ料金納付システムによって創作されたことが保証される。
【０１４２】
５． 署名キーはフィールド６に表示されるキーＩＤを有することを確認される。
【０１４３】
６． メッセージのフィールド７の内容を、５で確認されたキーによって解読する（Ｃ＿Ｄｅｃｒｙｐｔ手法、ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）。解読結果が仮のメッセージである。
【０１４４】
７． 仮のメッセージのフィールド１の内容はＫＴＭ（Ｃ＿ＵｎｗｒａｐＫｅｙ手法、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）によって解読される。結果、適当な移送キーオブジェクトが自動的に生成されカードに保存される。なお、該機構は再び暗黙のうちにキーの保全性と差出人の正確さを確認する。
【０１４５】
８． カードに同一のキーＩＤを持つキーが既に存在する場合、それは消去される。
【０１４６】
９． 暗号カードの全てのデータキーを読み込み、ＬＡＢＥＬ属性の生成カウンターの値、バイト１が新たに受け入れられたキーと同一かを確認する。同一であれば、これらのキーをカードから除去する。別の局所支払保証システムの暗号システムへの受け入れにおけるエラーによって、これらのキーは値転送センターＰＰにおいて放出されなかった。
【０１４７】
１０． 新たに受け入れられたキーのＬＡＢＥＬ属性のバイト２から６５に、ハッシュ値がＳＨＡ−１手法を用いて形成され、これはキーＩＤおよび戻り値としての正のメッセージとともに返送される。
【０１４８】
１１． 暗号カードによるユーザーのセッションを終了する。
【０１４９】
１２． プロトコルメッセージを戻り値から創作し、ＺｉｎＳセントラルシステムに送信する。
【０１５０】
１３． このキーＩＤのために保存されている失敗した試行がリセットされる。
【０１５１】
この適用例の変形は、ルーチンの１つまたはＭＡＣの確認の失敗である。この場合、さらなる処理は打ち切られ、キーＩＤ、エラーコードおよびエラーメッセージを含む戻り値が返送される。キーＩＤについて、保存されている失敗した試行の数が１つずつ増加する。この数が３に達すると、最も新しく転送された戻り値からプロトコルメッセージが創作され、中央支払保証システム（ＺｉｎＳセントラルシステム）に送信される。
手動での初期化の場合、さらに受け入れの結果が安全性管理者のモニターに表示される。
【０１５２】
手順２から１０をカードソフトウェアにおいて直接実行することが好ましい（埋め込みコード）。これによって性能および違法に対する安全性（特に初期化ベクターＩＶおよびＫＴＭｓにおいて）が向上する。
データキーのクリーンアップは繰り返し、好ましくは定期的に、支払保証システムの可能な限り多くの、好ましくは全ての暗号システムにおいて行われ、これによって既に不要となったデータキーが消去される。
【０１５３】
［データキーのクリーンアップの手続き］
１． カード上の全てのデータキーＫＤを確認し、そのＩＤ（ＣＫＡ＿ＩＤ属性）によって確認順に分類する。
【０１５４】
２． このリストの各キーについて、以下の確認手続きを行う。
Ｉ． キーの後継を決定する（次に大きいＩＤ）。
ＩＩ． 存在する場合、以下を証明する。
（１） 前者の正当性の終了を示す後継のＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性が現在のシステム日付より小さいかどうか。小さい場合は、リストの現在処理されているキーを消去する。
（２） 後継の生成カウンター（ＣＫＡ＿ＬＡＢＥＬ属性のバイト１）が現在処理されているキーの生成カウンターと同一かどうか。同一の場合は、リストの現在処理されているキーを消去する。
【０１５５】
キー処理は中央支払保証システムのサーバー（ＺｉｎＳセントラルサーバー）においてプロトコル処理されることが好ましい。この適用例によってプロトコル処理されるキーは移送キーとデータキーである。
【０１５６】
個々の配布ジョブについて、キーメッセージが送信された有効な暗号システムを示すプロトコルが作成される。個々のシステムと配布ジョブについて、ステータス“送信済み”における最初のセットである分離入力が生成される。
個々のキー処理の成功および失敗の後に、個別の暗号システムはプロトコルメッセージを生成し中央支払保証システム（ＺｉｎＳセントラルシステム）に送信する。この配布はＪＭＳキューによって、あるいはデータベース複製によって行われる。
【０１５７】
中央支払保証システムの領域において、メッセージは受信された後で前記のプロトコル入力のアップデートに用いられる。この目的のために、ステータス“処理成功”／“失敗”および、あるいはエラーコードとメッセージもが保存される。
【０１５８】
プロトコルメッセージの処理に続いて、全ての暗号システムによって組み込みが成功した配布ジョブが存在するかどうかが確認される。存在する場合、特に値転送センターの領域内の、付随するキーの放出が初期化される。システムがエラーを報告したらすぐに、負の状態を持つ対応するエラーメッセージが値転送センターの領域内において生成される。
キー放出が呼び出されているという事実は配布ジョブによって注意され、これによって与えられたジョブに追加の放出は実行されない。しかし警告が長く入力されないほど、放出サービスへの接触の新たな試行が一定の間隔で行われる。
【０１５９】
定義された期間の後、好ましくは数日後、例えば３日後に、全ての暗号システムからのフィードバックが受信されない場合に、特別な変形が存在する。この期間の終了後に、負の放出メッセージが値転送センターに送信される。
【０１６０】
キー割り当てシステムが、管理者にキー配布ジョブのステータスを確認することを可能とするユーザーインターフェースを持つことが好ましい。個々の配布ジョブについて以下のデータが表示される。
・配布メッセージが送信されたシステムの数
・処理成功が報告されたシステムの数
・処理の結果が報告されていないシステムの数
・処理の失敗が報告されたシステムの数
【０１６１】
さらに、個々のシステムの現在のステータスが表示される詳細な表を作成可能である。
代替として、割り当てカード上に保存されるキーを局所的に表示することも可能である。
【０１６２】
配布ジョブを生成された全てのキーを中央支払保証システムの領域においてアーカイブすることが有利である。局所システムにおいてはアーカイブを行わないことが好ましい。ここで、キーはカードの不揮発性メモリーに保存する。同様に放出されたキーメッセージのみをアーカイブする。
【０１６３】
特定の暗号システムについて、移送キーおよびデータキーのキー復旧は中央で可能である。この場合、アーカイブからの現在のキーが確認され、特定の暗号システムへ送信される。この目的のために、プロトコルメッセージも同様に生成される。この形式のキー配布において、放出メッセージのみは存在しない。
【０１６４】
マスター移送キーＫＴＭが消失した場合、対応する暗号システムが新たな初期化のために安全性管理者への送信を行うか、あるいは安全性管理者がサイト上で各システムを初期化しなければならない。
【０１６５】
ウェブセントリーカードの特別な安全性手段、複数のスマートカードへの配布、および多段キーシステムによって、マスター移送キーＫＴＭは漏洩に対し確実に安全性を保証される。
しかし、マスター移送キーの置換が行われた場合は、新たなマスター移送キーＫＴＭおよび新たな署名キー、移送キー、データキーが生成されなければならない。
【０１６６】
これらを局所支払保証システムの全ての暗号システムへと受け入れなければならない。全ての暗号システムが中央管理サイトへの移送を行いこれを戻さなければならず、あるいは安全性管理者が局所支払保証システムの全てのサイトへ移動しなければならないので、これはより多くの労力を伴う。したがって、マスター移送キーＫＴＭについての本発明による安全性機構を利用することは特に有利である。
先のマスター移送キーＫＴＭはいわゆる”潜在ＬＭＫ“としてカード上に残り、これは安全性管理者によって適当に消去されなければならない。
【０１６７】
キーの取り扱いと解読は埋め込みコードとしてカード上に存在するべきである。この様式では、高い安全性が達成できるだけでなく暗号システムの性能向上が期待できる。
【０１６８】
暗号カードは提示された拡張とともに、下に列記した標準ＰＫＣＳ＃１１の機能を含むことが好ましい。
・Ｃ＿ＣｌｏｓｅＳｅｓｓｉｏｎ
・Ｃ＿ＧｅｔＳｌｏｔＬｉｓｔ
・Ｃ＿Ｉｎｉｔ
・Ｃ＿Ｉｎｉｔｉａｌｉｚｅ
・Ｃ＿Ｌｏｇｉｎ
・Ｃ＿Ｌｏｇｏｕｔ
・Ｃ＿ＯｐｅｎＳｅｓｓｉｏｎ
【０１６９】
さらに、恒常的に保存される機能はサードパーティーのさらなる拡張を含むべきではなく、ここで要求される拡張は支払保証システムの暗号カードの機能としてのみ統合される。
【０１７０】
ＰＫＣＳ＃１１ ＤＬＬの潜在キー取り扱い手法を指定するために、これらの手法に接頭辞を与える。この接頭辞はＣＥ＿として定義される。ここで、ＣＥは暗号の拡張（Ｃｒｙｐｔｏ Ｅｘｔｅｎｓｉｏｎ）を表す。
【０１７１】
各埋め込み手法は形式ＣＫ＿ＲＶの戻り値を供給し、これはｐｋｃｓ１１．ｈ包含ファイルの固定の構成要素として定義される。埋め込み手法の実装の間において、追加のエラー戻り値が定義され、統合のためのＣ＋＋ヘッダーファイル内に設けられる点で有利である。この方法は、埋め込み手法の呼び出しを通して、ハードウェア上に組み込まれた様々なＰｋｃｓ１１を呼び出せる点で有利である。ここでの別の利点は、暗号カードのソフトウェア内での完全に新しく確立されたキーの取り扱いである。
【０１７２】
［この手法の構文法を説明する例］
ＣＫ＿ＲＶ ＝ ＣＥ＿ＭｅｔｈｏｄＮａｍｅ （ｐａｒａｍｅｔｅｒ ｌｉｓｔ）
パラメータリスト内において、結果で埋められる必要のあるパラメータは参照による呼び出しによって転送される。手法の名前は有意味な語の組み合わせによって形成され、該手法が行うことの正しい意味を示す。
語の選択は内容を意味する関連付けを許容するように、例えば英語の技術用語の使用によってなされる。
【０１７３】
２つの計数形式の導入により、異なる埋め込み手法の機能性が証明される。キーの形式と属性について、該計数形式の間には相違がある。
ＣＥ＿ＥｎｕｍＫｅｙ ＝ ｛ ＣＥ＿ＫＴ， ＣＥ＿ＤＴ， ＣＥ＿ＳＥ， ＣＥ＿ＫＡ ｝
【０１７４】
ＣＥ＿ＫＡは特別な位置を仮定する。これは１つのキーではなく全てのキーのセットである。このＥｎｕｍＥｌｅｍｅｎｔが示されると、手法はカード内に含まれる全てのキーに関連する機能性を実装する。
ＣＥ＿ＥｎｕｍＫｅｙＡｔｔｒｉｂｕｔｅ ＝ ｛ ＣＥ＿ＩＤ， ＣＥ＿ＬＡＢＥＬ， ＣＥ＿ＳＴＡＲＴＤＡＴＥ， ＣＥ＿ＥＮＤＤＡＴＥ ｝
【０１７５】
必要な定義はｐｋｃｓ１１．ｈファイルへと引き継がれる。定義された拡張はｐｋｃｓ１１．ｈファイルに封入された分割ヘッダーファイル内に位置させることができる。埋め込み手法の実装のためには様々な機構が可能である。
【０１７６】
暗号環境において、関連する証明はそれに利用可能なＰＫＣＳ＃１１手法によって自律的に実行される。
ＣＫ＿ＲＶ ＣＥ＿Ｄｅｃｒｙｐｔ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ ［ ］ ｍｅｓｓａｇｅ， ＣＫ＿ＢＹＴＥ＊ ｐｏｓｔａｇｅＩＤ
ＣＫ＿ＢＢＯＯＬ ｂＯｋ）
【０１７７】
［機能の説明］
埋め込み暗号手法パラメータメッセージ内の５７バイトの長期の日付を受信し、この日付は郵便証印のマトリクスコードに対応する。以下の作業手順の説明における計数は１から始まる。
【０１７８】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターとして、最初の２バイトは０で埋められ、バイトｆ６からｆ１０およびｆ１４がマトリクスコードに付加される。
【０１７９】
［第２の手順：用いるＫＤの決定］
キー位相インジケーターはバイトｆ１４に含まれ、どのキーが用いられるかを表示する。キー位相インジケーターはＣＫＡ＿ＩＤキー属性内に保存され、キーを明白に識別する。以下で説明されるキーの取り扱いは効果的なキーの発見を可能とすべきである。
【０１８０】
［第３の手順：含まれる暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭにおいて使用される機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣである。バイトｆ１５からｆ３８の２４バイトが解読され、解読結果の最初の１２バイトがパラメータのＰｏｓｔａｇｅＩＤによって出力される。解読が成功すると、手順４あるいは手順５の手順が繰り返される。
【０１８１】
［第４の手順：ハッシュ値の形成とクリーンアップ］
特別に構成された７７バイトの大きいデータブロックが、日付のハッシュ値の形成の根拠となる。
バイト１から５３：マトリクスコードの最初の５３バイトに対応
バイト５４から６５：現在の暗号化されていないメッセージ部分（ＰｏｓｔａｇｅＩＤ）の最初の１２バイトに対応
バイト６６から７７：現在の暗号化されていないメッセージ部分の最後の１２バイトに対応
ハッシュ値はＳＨＡ−１を用いて形成され、この手続きの後で最初の４バイトがバイトｆ５４からｆ５７に一致しなければならない。一致しない場合、日付は正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順５となる。
【０１８２】
［第５の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
ＣＫ＿ＲＶ ＤＥ＿ＶｅｒｉｆｙＭｓｇ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ ［ ］ ｍｅｓｓａｇｅ， ｉｎｔ ｌｅｎｇｔｈ，
ＣＫ＿ＢＢＯＯＬ ｂＯｋ）
【０１８３】
証明手続きの一般的なデータブロックメッセージを以下に示す。
【０１８４】
【表９】
【０１８５】
未使用のフィールドはゼロで埋められる。手法の操作の様式はパラメータＭｓｇＴｙｐｅによって決定される。
生成されたデータブロックはＭｓｇＴｙｐｅのＫＴおよびＫＤへのメッセージに転送される。データブロックは個々の受信されたメッセージで埋められる。
【０１８６】
ＭｓｇＴｙｐｅのＫＴへの機能割り当てＣＥ＿ＶｅｒｉｆｙＭｓｇ ＫＴはＭＥＳＳＡＧＥ属性内の完全な移送キーメッセージ、およびＬＥＮＧＴＨ属性内のその長さを受信する。この埋め込みメッセージは受信者における移送キーメッセージの保全性を保証する。証明の動作のために、以下の手順を行う必要がある。
【０１８７】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターはゼロで埋められる。
【０１８８】
［第２の手順：受信した暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭで用いる機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤである。可変ＭＡＣフィールドのバイトが解読される。解読の間にエラーが起こった場合は、手続きは手順４となる。
【０１８９】
［第３の手順：ハッシュ値のクリーンアップ］
日付のハッシュ値の形成のために、移送キーメッセージのフィールド１＋２＋５＋６＋８からハッシュを形成し、これを手順２のハッシュと比較する。ＳＨＡ−１に使用するハッシュ値が形成される。ハッシュ値が同一でない場合は、日付が正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順４となる。
【０１９０】
［第４の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
【０１９１】
ＭｓｇＴｙｐｅ ＫＤについての機能割り当てＣＥ＿ＶｅｒｉｆｙＭｓｇの後で、ＭＥＳＳＡＧＥ属性内の完全な移送キーメッセージ、およびＬＥＮＧＴＨ属性内のその長さが転送される。この埋め込みメッセージは受信者における移送キーメッセージの保全性を保証する。証明の動作のために、以下の手順を行う必要がある。
【０１９２】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターはゼロで埋められる。
【０１９３】
［第２の手順：受信した暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭで用いる機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤである。可変ＭＡＣフィールドのバイトが解読される。解読の間にエラーが起こった場合は、手続きは手順４となる。
【０１９４】
［第３の手順：ハッシュ値のクリーンアップ］
日付のハッシュ値の形成のために、データキーメッセージのフィールド１＋２＋４＋３＋６＋７＋８からハッシュを形成し、これを手順２のハッシュと比較する。ＳＨＡ−１に使用するハッシュ値が形成される。ハッシュ値が同一でない場合は、日付が正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順４となる。
【０１９５】
［第４の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
【０１９６】
これらの埋め込みキー取り扱い手法はラップされたキーの受け入れおよび効果的なキー管理を含むべきである。形式ＫＳ、ＫＤおよびＫＴのキーが受け入れられるべきである。
ＣＫ＿ＲＶ ＣＥ＿ＩｍｐｏｒｔＫｅｙ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ＿ＰＴＲ ｄａｔａ，
ＣＫ＿ＵＬＯＮＧ ｌｅｎｇｔｈ， ＣＫ＿ＢＹＴＥ＊ ＨａｓｈＶａｌｕｅ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ＣＫ＿ＣＨＡＲ ［ ］ ＫｅｙＫＴＩＤ）
【０１９７】
機能割り当てＣＥ＿ＩｍｐｏｒｔＫｅｙは以下に述べるように行われることが好ましい。
ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ＷＥＢＳＥＮＴＲＹ機構がラッピングに用いられる。よって、ラッピングを解くためには同様の機構が必要である。得られたキーはラッピング解除によって暗号ハードウェアに受け入れられ、２回目に受け入れられたキー、つまり同一のキー位相を持つキーによって、古いキーが上書きされる。
【０１９８】
ラップされたキーはＤＡＴＡパラメータに転送され、ＬＥＮＧＴＨ属性内のその長さが転送される。キーの長さはキー属性の充填に依存する。キー形式はＫｅｙＴｙｐｅパラメータによって証明され、これによって処理される。
その後キーはキャッシュ操作内に保持されたキー管理に移され、利用可能であれば、複製の前者は消去される。
【０１９９】
ＫｅｙＫＴＩＤパラメータによって識別されたＫＴにより、ＤＴは解読され、他の全てのキー形式についてこのパラメータは考慮されず、ゼロで埋められる。
ＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性の従属は重要である。それは前者のキーの日付を示す。
【０２００】
受け入れられたキーのキー属性は、それによってＳＨＡ−１を用いてハッシュ値を形成する乱数を含む。ハッシュ値は埋め込み手法のＨａｓｈＶａｌｕｅパラメータに戻される。ハッシュ値はキー確認メッセージに必要である。
【０２０１】
ラップ解除機構あるいはハッシュ形成の間のエラーにおいて、適当なエラーコードが戻り値あるいはＣＫＲ＿ＯＫに出力される。
ＣＫ＿ＲＶ ＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ｉｎｔ＊ ｃｏｕｎｔｅｒ）
【０２０２】
機能割り当てＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔは、個々のキー形式のキーがどれだけキャッシュ操作内のキー管理のカード上に登録されているかを示す。この様式においては、以下に述べる手法によってキー属性を読み出すことができる。
この方法は以下のように定義される。
ＣＫ＿ＲＶ ＣＥ＿ＧｅｔＡｔｔｒｉｂｕｔｅ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ＣＥ＿ＥｎｕｍＫｅｙＡｔｔｒｉｂｕｔｅ ＫｅｙＡｔｔｒｉｂｕｔｅ，
ｉｎｔ ｐｏｓ，
ＣＫ＿ＢＹＴＥ ［ ］ ＊ ａｔｔｒｉｂｕｔｅ，
ｉｎｔ＊ ｌｅｎｇｔｈ）
【０２０３】
キー形式はＫｅｙＴｙｐｅパラメータと、キーの形式によって暗号ハードウェア上の異なるキー形式が異なるリストに記録されるときに読まれる表によって決定される。
【０２０４】
ＫｅｙＡｔｔｒｉｂｕｔｅパラメータによって読み出される属性が指定され、ＩＴＥＭパラメータによって表の中の始点が示される。最初にその最大値を、全てのキーあるいは１つのキー形式についてＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔ手法を用いて獲得しなければならない。ＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性が出力されると、最後の現在のキーが（同じ形式の新たなキーが受け入れられるまで）理論上無限に正当であり、またそのＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性において同一のキー形式の前者のキーの終了日付を含み、そしてこの示されたキーのＣＫＡ＿ＥＮＤ＿ＤＡＴＥが出力される。
【０２０５】
日付についての属性は８バイトの固定された長さを有するのに対し、ＣＳＫ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性は１２８バイトの固定された長さを有する。これらの２つのパラメータについてのキー内の属性が１２８バイトより短い場合は、１２８までの残りのバイトは０で埋められる。したがって、ユーザーは常に当該の手法に充分なメモリーを提供できる。ユーザーの提供するバッファーが小さすぎる場合は、情報はトリミングされ、この結果のメッセージがＣＫ＿ＲＶによって伝達される。
ＣＫ＿ＲＶ ＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ｉｎｔ＊ ｃｏｕｎｔｅｒ）
【０２０６】
機能割り当てＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓはカード内の失効したキーを探し、これをカードから消去する。失効したキーはシステム日付が後継のキーのＣＫＡ＿ＥＮＤ＿ＤＡＴＥ（２．５．８参照）より古いことによって識別され、これはＫＴおよびＫＳにも適用される。選択的消去はＥｎｕｍＴｙｐｅによって可能となり、ＣＥ＿ＫＡによってカード全体を消去できる（ＬＭＫのみ保持される）。この手法はキーの受け入れの実行の際には有効化を許容されないことが重要である。これは埋め込みコード内で制御され、適当な戻り値で示されることが好ましい。この方法により、内部キー管理において不確定な副作用が回避される。
サイドチャネルからの改ざんの可能性を除外するために、支払保証システムと値転送センターとの間のインターフェースは厳密であることが好ましい。
【０２０７】
値転送センター（郵便料金ポイント）と中央支払保証システムとの間のインターフェースの構造を図３に示す。
値転送センター（郵便料金ポイント）のＫｅｙＭａｎａｇｅｍｅｎｔ構成要素において生成されるキーが支払保証システムの暗号システムに配布可能であることにより、キー配布のためのインターフェースが中央支払保証システムに設けられる。
キーの配布成功と処理の後で支払保証システムがキーを放出可能であることにより、値転送センターによって支払保証システムにキー放出インターフェースが設けられる。
【０２０８】
両計画において主にＪａｖａ（登録商標）を用いているので、セッションビーンを用いる適用インターフェースの実現が推奨される。２つのシステムを分離するために、サービスはＪＮＤＩを用いて指定のサービスで調べるべきである。
【０２０９】
キーデータをＺｉｎＳセントラルシステムに受け入れるために必要な機能性がセッションビーンによって提供される。全体の通信は図４に示される。
データキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための処理手順が図４に示される。
【０２１０】
処理ルーチンＩｍｐｏｒｔＫｅｙによってデータキーセットがＺｉｎＳセントラルに転送される。
ＡＳＮ．１メッセージを使用することで、この処理ルーチンは受信メッセージを準備し、メッセージをデータベースに保存させる。処理ルーチンＩｍｐｏｒｔＫｅｙはそれからＣＷＭＳによるキーデータのＺｉｎＳローカルシステムへの配布を初期化する。
【０２１１】
データのデータベースへの受け入れシーケンスとそれに続くメッセージの配布は監視されるべきである。これによって受信されたデータが作業の前に安全性を保証される。この方法の利点は、エラーの領域のイベントをよりよく再構成でき、データの消失の場合には必要ならデータベースにアクセスできることである。
【０２１２】
この時点においてＡＳＮ．１フォーマットがサポートされているかが不明瞭なので、ＩｎｓｅｒｔＫｅｙＤａｔａ手法のパラメータはまだ指定されていない。しかし、詳細なメッセージを郵便料金ポイントにも送信可能とするためには２つのパラメータが装備されなければならないであろう。
【０２１３】
ＺｉｎＳセントラルにおいて、キー割り当てシステムの配布手法は下記の原因となる。
【０２１４】
１． ＺｉｎＳセントラルサーバー上でのキーメッセージのアーカイブ。
【０２１５】
２． ＶｉｂｒｉｓによるＣＷＭＳインターフェースによる、郵便料金ポイントから個別のメールセンターへのキーメッセージの配布。ＣＷＭＳの構造と利用はこのインターフェースの説明書に見られる。
【０２１６】
３． 個々のメールセンターへの配布と受け入れが完了した後に、付随する返送メッセージを生成する。
【０２１７】
データは値転送センター（郵便料金ポイント）からＡＳＮ．１フォーマットで伝達される。付随する応答も同様にＡＳＮ．１フォーマットと予想される。しかし、このフォーマットの代わりに他のフォーマットを用いることももちろん可能である。特定のフォーマットは適当なパーサーによって使用のために適用される。
ＡＳＮ．１の好ましいデータフォーマットは以下のものである。
【０２１８】
［移送キーの配布メッセージ］
ＴｒａｎｓｐｏｒｔＫｅｙＭｅｓｓａｇｅ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＭｓｇＴｙｐｅ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ｆｉｘ ‘ＫＴ’ ）
Ｖｅｒｓｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ）
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ）
ＳｉｇＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＳｉｇｎａｔｕｒｅＫｅｙ ｕｓｅｄ ｆｏｒ ＭＡＣ ）
ＴｒａｎｓＫｅｙＥｎｃｒｙｐｔ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＴｒａｎｓｐｏｒｔＫｅｙ ｗｒａｐｐｅｄ ｗｉｔｈ ＬＭＫ ）
ＭＡＣ ＯＣＴＥＴ ＳＴＲＩＮＧ （ ＭＡＣ ｏｖｅｒ ａｌｌ ｐｒｅｖｉｏｕｓ ｅｌｅｍｅｎｔｓ ）
【０２１９】
［データキーの配布メッセージ］
ＰｏｓｔａｇｅＫｅｙＭｅｓｓａｇｅ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＭｓｇＴｙｐｅ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ｆｉｘ ‘ＫＤ’ ）
Ｖｅｒｓｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ）
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ）
ＫｅｙＧｅｎｅｒａｔｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ａｓｃｅｎｄｉｎｇ ）
ＳｉｇＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＳｉｇｎａｔｕｒｅＫｅｙ ｕｓｅｄ ｆｏｒ ＭＡＣ）
ＴｒａｎｓＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＴｒａｎｓｐｏｒｔＫｅｙ ）
ＤａｔａＫｅｙＥｎｃｒｙｐｔｅｄ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＰｏｓｔａｇｅＫｅｙ ｗｒａｐｐｅｄ ｗｉｔｈ ＬＭＫ
ａｎｄ
ｅｎｃｒｙｐｔｅｄ ｗｉｔｈ ＴｒａｎｓｐｏｒｔＫｅｙ ）
ＭＡＣ ＯＣＴＥＴ ＳＴＲＩＮＧ （ ＭＡＣ ｏｖｅｒ ａｌｌ ｐｒｅｖｉｏｕｓ ｅｌｅｍｅｎｔｓ ）
｝
Ａｌｓｏ ｓｅｅ ｓｅｃｔｉｏｎ ２．４．６．
【０２２０】
［放出メッセージ］
ＫｅｙＥｘｃｈａｎｇｅＲｅｃｅｉｐｔ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ｒｅｃｅｉｖｅｄ ｋｅｙ ）
ＫｅｙＬａｂｅｌＨａｓｈ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＳＨＡ−１ ｈａｓｈ ｏｆ ＣＫＡ＿ＬＡＢＥＬ ｏｆ ｒｅｃｅｉｖｅｄ ｋｅｙ ）
Ｓｔａｔｅ ＢＯＯＬＥＡＮ， （ ＴＲＵＥ／ＦＡＬＳＥ ｔｏ ｅｎａｂｌｅ／ｄｉｓｍｉｓｓ ｋｅｙ ）
Ｍｅｓｓａｇｅ ＯＣＴＥＴ ＳＴＲＩＮＧ （ Ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ ｓｕｃｃｅｓｓ／ｆａｉｌｕｒｅ ）
｝
【０２２１】
データ構造は異なるセットアップを持つことができる。しかし、考慮される全ての情報の伝達を許容し、また小さいデータの送信の労力の説明となるので、提示された実施例におけるセットアップは特に有利である。特に、データはＣＷＭＳによって、好ましくは郵便サービス提供者のメールセンター内にある、局所支払保証システムへと伝達される。
【０２２２】
ＡＳＮ．１フォーマットが用いられる場合、データはまず内部キーメッセージに解析されなければならず、このドキュメント内に定義されるメッセージが直接使用される場合にはそれは不要となる。
【０２２３】
ＣＷＭＳによって受信されるデータパケットは、以前にこのドキュメント内に定義されたキーメッセージに対応する。これらのメッセージはそれから、最初にタイトル“データキーＫＤの属性”の上のデータ表に適合された後で、埋め込みコードのＶｅｒｉｆｙＭｓｇ手法に従属される。証明の後で、キーの受け入れが埋め込みコードによって開始され、あるいは適当なエラーメッセージが生成される。ＣＥ＿ＩｍｐｏｒｔＫｅｙ埋め込みコード手法における受け入れデータ構造の点において、キーメッセージとページ１２から１４を比較する。古いキーの消去と更新は前期の埋め込みコード手法によって自動的に行われ
【０２２４】
失効したキーを暗号ハードウェアから毎日除去するＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓが毎日呼び出される事が必要である。受け入れの間に、複製キーが消去され新しいものと置き換えられることがＣＡ＿ＩｍｐｏｒｔＫｅｙ手法によって保証される。
埋め込みコード手法はＪａｖａ（登録商標）クラス ＣｒｙｐｔｏＡｄａｐｔｅｒｓによってアプリケーションに結び付けられる。ＣｒｙｐｔｏＡｄａｐｔｅｒｓは、埋め込みコードおよび他のＰＫＣＳ＃１１手法が提示する（同様に指定された）全ての手法を提示する。
【０２２５】
ＪＮＩによって、Ｚａｘｕｓに提供されるＤＬＬを静的に連結したＤＬＬ（ＣｒｙｐｔｏＡｄａｐｔｅｒ．ＤＬＬ）が用いられる。静的連結によって安全性リスクがさらに最小化される。
【０２２６】
ＪＮＩインターフェースのＣ＋＋実装によって、個々の要求されたセッションのエラーの取り扱いが提供される。これに関連してＰＣＦＭデザインドキュメントの“マルチスレッディング”下のステージ３を参照。暗号ハードウェアをマルチスレッディングモードにおいて初期化し、作業者がＤＬＬに登録されエラー取り扱いが作業者に特異的に確立された結果として、ログインの後で個々の作業者が自身のセッションを得る（ｇｅｔＳｅｓｓｉｏｎ， Ｃ＿ＧｅｔＳｅｓｓｉｏｎ）ことで、作業者の構想が支援される。ＤＬＬの本流はログインによって移動され、Ｐｋｃｓ＃１１手法および埋め込み手法の実行のためのエラー取り扱いを同様に有する。
【０２２７】
実装の概観を図６に示す。キーリスト、および埋め込み手法によって提供されるコードは除去される。あるいは、構造のセットアップは同一であるように選択されなければならない。
【０２２８】
［ＤＬＬの接続］
好ましい封入と有利なエラー取り扱いの例を図７に示す。
キーリストが暗号ハードウェアの埋め込みコードに完全に保持されている場合は、キーリストの実装は必要ない。ＧｅｔＡｔｔｒｉｂｕｔｅ手法は単一の埋め込みＣＥ＿ＧｅｔＡｔｔｒｉｂｕｔｅ手法に削減される。同じ理由で、受け入れのための呼び出しおよび実装も、必要なデータの転送の後で埋め込みコードによって自動的に行われるので削減される。
【０２２９】
拡張されたエラー定数リストが埋め込みコード内に設けられる。
郵便料金ポイントからのキーメッセージがＺｉｎＳセントラルのデータベースに保存され、欠陥のある局所支払保証システムの後での置き換えを可能としている。第一にそのようなメッセージをデータベースに組み込むことが要求され、第二に管理情報が受信される。
その結果、以下のデータベース表が必要となる。
【０２３０】
【表１０】
【０２３１】
郵便料金ポイントに受信されることでキーデータがキーメッセージを保存し、局所支払保証システムの不良の場合、キーメッセージのアーカイブによって、アーカイブされたキーを受け入れることで不良の局所支払保証システムが残りの局所支払保証システムと調整される。保存の前にメッセージをＡＳＮ．１によって解析し局所システムに伝達する必要がある。分割された形態のデータレコードは保存様式として好ましい。これは、ＣＥ＿ＶｅｒｉｆｙＭｅｓｓａｇｅ埋め込み手法に用いられるデータブロックを説明する表に対応する。
【０２３２】
【表１１】
【０２３３】
このデータレコードは重要性を有する。これは第一にメールセンター、好ましくは郵便サービス提供者の郵送システムに統合された全てのメールセンターの局所支払保証システムから受信されたフィードバックを評価するとともに、配布手続きの間に時間が超過すれば常に、可能なエラー解析およびシステムオペレータへの警告を行う。
【０２３４】
同じ理由で、この表は管理情報処理を要する。適用可能であれば、これは入力ＳＮＩｔｅｍＮｏを用いて付随するＴｒａｎｓｐｏｒｔＫｅｙＤａｔａおよび個別の（８３）メールセンターのＴｒａｎｓｐｏｒｔＫｅｙＲｅｐｌａｙＭｅｓｓａｇｅの割り当てと評価を可能とする。
【０２３５】
【表１２】
【０２３６】
この表において、局所支払保証システムの個別の応答メッセージは郵便サービス提供者のメールセンター内に受け入れ手続きの機能としてアーカイブされる。
【図面の簡単な説明】
【０２３７】
【図１】本発明によるキーの配布の特に好ましい実施例を示す図。
【図２】本発明によるキー配布システムの適用例を示す図。
【図３】中央支払保証システム（ＺｉｎＳセントラルシステム）と値転送センター（郵便料金ポイント）との間のインターフェースの概略図。
【図４】データキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための手順を示す図。
【図５】付随する暗号を含む、中央支払保証システム（ＺｉｎＳセントラルシステム）から局所支払保証システムへのキーの配布の概略図。
【図６】ＤＬＬインターフェースの接続状態を示す概略図。
【図７（Ａ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【図７（Ｂ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【図７（Ｃ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、料金納付キーを用いて生成され郵便物に添付される郵便証印の信頼性証明の方法に関する。該郵便証印に含まれる暗号情報を解読し、郵便証印の信頼性証明に用いる。
【背景技術】
【０００２】
デジタル郵便証印を有する郵便物の作成手続きは公知である。
郵便物の差出人がデジタル郵便証印をより容易に作成できるように、例えば、ドイチェポストＡＧの用いる料金納付システムによって、顧客のシステムにおいて郵便証印を作成し、望ましいインターフェースを介してそれをプリンターから出力することが考えられる。
この形式のための方法の１つが、ドイツ予備出願公開ＤＥ １００ ２０ ４０２ Ａ１において開示されている。
【０００３】
この方法の不正な使用を避けるために、デジタル郵便証印は、例えば該郵便証印の作成を制御する顧客のシステムの識別に関する暗号情報を含むものとする。
【０００４】
国際特許ＷＯ ０１／１７１６０ Ａ１はキー配布の手法に関し、ここでキーは中央管理ユニットによって生成され、暗号化された形式で配布ユニットによって暗号装置へと伝達される。これらの装置は、キーの受信の成功あるいは失敗についてのメッセージを配布ユニットから管理ユニットへと送信する。キーを受信できない場合は、暗号化していない形式で再度付随の暗号装置へと送信する。
【０００５】
欧州特許ＥＰ ０ ８５４ ４４４ Ａ２において、料金納付装置によって作成された郵便証印の暗号化と確認のための手法が開示されている。ここでは、料金納付装置に実装されたマスターキーから追加のキーが派生され、郵便証印の作成に用いられる。メールセンターにおいても、追加のキーは同様に生成され郵便証印の確認に用いられる。
【０００６】
米国特許５，１５０，４０８号において、暗号化したメッセージをキー配布ユニットによって通信装置に伝達する、例えば無線ネットワーク等の、通信システムにおけるキー配布のための手法が開示されている。このメッセージが受信された後で、通信装置がキー配布ユニットへと確認を送信する。
【０００７】
暗号化したデータの伝達のための既知の規格ＡＮＳＩ Ｘ９．１７（１９９４年１０月７日付けのＵＲＬ ｈｔｔｐ：／／ｃｓｒｃ．ｎｉｓｔ．ｇｏｖ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｎｉｓｔｐｕｂｓ／８００−７／ｎｏｄｅ２０９．ｈｔｍｌを参照）は複数のキーのキー階層構造に基づいている。ここでは、電子的に置換され通信パートナーの間で暗号化されて伝達される寿命の短いデータの暗号化のための１つ以上のデータキーと、該データキーの暗号化のための手動で置換されるキーが存在する。さらに、引用文献においてデータの暗号化のための既知のディフィーヘルマン手法が開示され、ここで通信パートナーは既知の数と秘密の乱数から共有キーを計算する。
【０００８】
欧州特許ＥＰ ０ ７３５ ７２２ Ａ２において、料金納付装置のためのキーの生成、配布および管理のためのキー管理システムが開示されている。ここでは、複数の高信頼領域が存在し、これらは該領域間の通信を可能とし該領域を制御するコンピュータに接続されている。キーの生成、インストール、証明および確認はそれぞれ高信頼領域の１つにおいて行われる。個々の領域は該領域のステータスをプロトコル処理したアーカイブに統合される。
【０００９】
この発明は、郵便証印の信頼性を素早く確実に証明可能とする方法の考案、という目的に基づいている。特に、該方法は大規模な、とりわけメールセンターまたは貨物センターでの証明手続きにおける利用に適していることが好ましい。
【発明の開示】
【００１０】
本発明によってこの目的は、請求項１による方法により達成される。
詳細には、信頼性証明の方法を、データキーを生成し中央データベース（ＺｉｎＳセントラルシステム）から局所支払保証システム（ＺｉｎＳローカル）へと伝達することが提供される。これは生成された料金納付キーと郵便物に添付された郵便証印を用いてなされ、郵便証印に含まれる暗号情報を解読して該郵便証印の信頼性の証明に用いる。
【００１１】
該方法の安全性を高めるためには、局所支払保証システムがデータキーを受け入れ、受け入れの結果を中央データベース（ＺｉｎＳセントラルシステム）に伝達することが有利である。
【００１２】
この方法の特に好ましい実施形態においては、受け入れの結果はデータレコードとして伝達される。
該データレコードはキーを含むことが好ましい。該キーには様々な属性を持たせることができる。特に、対称キーまたは非対称キーとすることができる。意図して使用することによって、該キーは情報の解読および／または暗号化に用いることができる。その性質によって、該キーによって情報を伝達することもできる。例えば、キーには料金納付キー、そのキーの生成、および／またはその終了日付に関する情報を持たせることができる。
【００１３】
キーの均質な置換を保証するためには、中央データベース（ＺｉｎＳセントラルシステム）において受け入れの結果を確認し、それを値転送センター（郵便料金ポイント）に伝達することが有利である。
【００１４】
前記方法のこの実施形態によって、受け入れの結果の機能として、値転送センターでのさらなる処理手順の実行が可能となる。
【００１５】
この結果は様々な方法で確認される。しかし、結果をキーの解読によって確認することが特に有利である。
【００１６】
前記方法の好ましい実施形態は、まずデータキーをほぼ全ての局所支払保証システム（ＺｉｎＳローカル）へと受け入れ、値転送センターにおいて該データキーを新たな料金納付キーとして放出し、続いて新たな郵便証印の作成に用いることを特徴とする。
前記方法のこの実施形態によって、支払保証システムで先に行われたキーの置換の機能としての値転送センターでのキーの置換が可能となる。この方法によって、既に局所支払保証システムに存在していた新たなキーを用いてのみ郵便証印が作成されることが保証される。これによって、局所支払保証システムにより個々の生成された郵便証印の信頼性を証明可能であることが保証される。
【００１７】
前記方法の、この特に好ましい実施形態は、局所支払保証システムでのキーの置換の機能としての値転送センターでのキーの置換の制御を伴うが、これを少なくともいくつかの本発明に関する他の処理手順と組み合わせることが特に有利である。
特に、複数の特徴の組み合わせによって、キーの置換を素早く確実に行われることと、個々のキーの置換の実行が証明されることとが保証される。
【００１８】
キーの置換が行われる際に、新たなデータキーを値転送センター（郵便料金ポイント）から中央支払保証システムへと伝達することが有利である。
ここで、値転送センターにおいてデータキーを移送キー（ＫＴ）を用いて暗号化することが特に有利である。
ここで、移送キーをマスター移送キー（ＫＴＭ）を用いて暗号化することが実際的である。
【００１９】
データキーは値転送センター内で生成することが好ましい。これにはデータキーが値転送センターへの移送中に不正に変化されることを防止できるという利点がある。
データの安全性をさらに高めるためには、データキーをキー識別情報とともに提供することが有利である。
キー識別情報もまた暗号化した形式で伝達することが有利である。
【００２０】
個々の暗号化および／または解読の手順において正当なデータキーが用いられていることを保証するためには、データキーを生成カウンターとともに提供し、さらに／あるいは生成カウンターとともに伝達することが有利である。
【００２１】
無効なキーの使用を避けるためには、料金納付キーを先のデータキーの終了日とともに提供し、さらに／あるいは終了日とともに伝達することも有利である。
【００２２】
前述のデータキーは１つ以上の部分的な証明や、郵便証印の作成、および／または郵便証印に含まれる情報の解読に用いることができる。
【００２３】
郵便証印に含まれる暗号情報の解読を部分的な証明に含むことが特に有利である。
【００２４】
暗号情報の解読を証明手順に統合することで、郵便証印の信頼性を確認し、証明をリアルタイムで行うことが可能となる。
【００２５】
さらに、部分的な証明の１つが暗号情報の作成の日付と現在の日付との比較を含むことが有利である。郵便証印の作成の日付の、特に暗号化された形式での統合がデータの安全性を高める。それは、郵便証印の作成の日付と現在の日付との比較によって郵便証印の二重使用を防止できるからである。
【００２６】
証明速度のさらなる向上のためには、読み取りユニットと証明ユニットとが同期プロトコルによって情報を交換することが有利である。
本発明の別の同様な実施形態においては、読み取りユニットと証明ユニットとは非同期プロトコルによって互いに通信する。
【００２７】
ここで、読み取りユニットから証明ユニットへとデータ電文を送ることが特に有利である。
該データ電文は郵便証印の内容を含むことが好ましい。
【００２８】
本発明のさらなる利点、特徴および実際的な改良は、従属する請求項と図面に基づいて説明される以下の好ましい実施形態の提示とから見つけることができる。
【００２９】
図１は本発明によるキーの配布の特に好ましい実施例である。
図２は本発明によるキー配布システムの適用例である。
図３は 中央支払保証システム（ＺｉｎＳセントラルシステム）と値転送センター（郵便料金ポイント）との間のインターフェースの概略図である。
図４はデータキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための手順である。
図５は付随する暗号を含む、中央支払保証システム（ＺｉｎＳセントラルシステム）から局所支払保証システムへのキーの配布の概略図である。
図６はＤＬＬインターフェースの接続である。
図７はコンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図である。
【発明を実施するための最良の形態】
【００３０】
以下において本発明を、ＰＣ料金納付システムに関して説明する。ここで、支払保証のための手順は、郵便証印の作成に用いられるシステムから独立している。
個別の証明ステーション、特にメールセンターにおける前記の分散証明が特に好ましいが、集中証明も同様に可能である。
【００３１】
本発明の特に好ましい実施例においては、前記の個別の証明ステーションは局所支払保証システムとし、これらは好ましくはデータ接続によって中央支払保証システムに接続される。
前記の特に好ましい実施例において、中央支払保証システムはまた値転送センターにも接続される。
値転送センターの特に好ましい実施例を、以下において郵便料金ポイントと呼ぶ。中央支払保証システムの有利な実施例を、以下においてＺｉｎＳセントラルと呼ぶ。
【００３２】
値転送センターと支払保証システムとの間に実装される技術的インターフェースは、暗号キーの置換からなる。
【００３３】
転送センターと支払保証システムとの間で置換されるキーは、作成された郵便証印が偽造ではないことを保証する。これは、郵便証印を形成する二次元バーコードの一部を該キーによって暗号化することで達成される。能力による理由のために、選択されたキーは対称キーなので、転送センターから支払保証システムへと伝達される必要があり、そこから個別のメールセンターに配布される。
【００３４】
キーの高信頼保存は特別な暗号カードを用いることによって保証される。本発明は、これらのキーをこの特別なハードウェアを用いて管理する複数の適用例を包含する。これらのキーの生成から送出、配布、分散システムへの受け入れまでの全体の寿命は、プロセスパラメータの最適化のために用いられる。
【００３５】
キー配布のための特に好ましいシーケンスを図１に示す。
図１に、値転送センターと中央支払保証システムとの間での特に好ましいキー配布を示す。
郵便証印の作成に用いられる料金納付キーの置換のための最初の手順１において、まず新たな料金納付キーが生成される。
【００３６】
前記のキーは郵便証印の生成のための異なるやり方に用いることができるので、ここで料金納付キーという語を限定した意味で理解することはできない。
例えば、料金納付キーを直接郵便証印の作成のために用いることができる。
【００３７】
しかし、改ざんに対して特に安全性の高いシステムによって、多重に暗号化したデータ内容を有する郵便証印を作成することも、可能であり特に有利である。ここで該データ内容は好ましくは複数の操作によって形成され、１つ以上の場所で操作の結果を料金納付キーとともに郵便証印に組み込む。
例えば、ドイツ予備出願公開ＤＥ １００ ２０ ４０２ Ａ１に開示される形式の暗号文字列は料金納付キーに組み込まれる。
【００３８】
郵便証印の不正な作成に対し防御をさらに向上するために、料金納付キーのイベント特有の置換を行う。
提示された例において、料金納付キーは所定の間隔をあけて、例えば事前に定義できる時間間隔の満了の後で、新たに生成される。
【００３９】
しかし、料金納付キーの新たな生成を他のパラメータの機能として、例えば郵便物の課金額および／あるいは支払済みの郵便物に基づいて行うことも可能である。
【００４０】
原則の問題として、新たな料金納付キーの新たな生成はどこでも行える。しかし、データの安全性を高めるためには、新たな料金納付キーの伝達の労力を最小限とし、キーを値転送センター内で、あるいは値転送センターの領域内で生成することが有利である。
【００４１】
不正に対する方法の高レベルでの防御を保証するためには、郵便証印に含まれる情報を局所支払保証システムの領域内、例えばメールセンターまたは貨物センター内において料金納付キーに基づいて解読することが有利である。
これを保証するために、料金納付キーを値転送センターから中央支払保証システムへと伝達する。この伝達は自動化することが好ましい。
【００４２】
置換は支払保証システムのサーバー（ＺｉｎＳセントラルサーバー）を介して実施することが好ましい。値転送センター（郵便料金ポイント）を設定する必要はない。サーバーは値転送センター（ＺｉｎＳローカルシステム）とそれに属する暗号システムを認識する必要がないので、ＺｉｎＳセントラルサーバーのみが前記サーバーとして重要である。
【００４３】
好ましい対称型の料金納付キーの新たな生成の後で、後者は中央支払保証システムへと安全に伝達され（図１の手順２）、そこから局所支払保証システム内の暗号システムへと配布される（図１の手順３）。局所支払保証システム内から受け入れ操作の結果が返送され（図１の手順４）、キーの受け入れの成功が確認される。結果を中央システムでコンパイルし、確認し値転送センター（郵便料金ポイント）へと伝達する（図１の手順５）。
【００４４】
キーの全ての局所支払保証システム内の暗号システムへの受け入れが成功すると、値転送センター（郵便料金ポイント）において放出され、続いて新たな郵便料金額の生成に用いられる（図１の手順６）。
【００４５】
好ましい対称型の料金納付キーは、料金納付キーを用いて作成される郵便証印の偽造への安全性において不可欠な部分であり、該郵便証印は例えば二次元バーコードの形式とする。したがって、これらのキーの置換は強力な暗号法によって安全を確保する必要がある。これを保証するためには、以下の点を支持することが特に重要である。
・内容の機密性：伝達の間に、第三者が伝達されるキーを読み出すことが可能であってはならない。さらに、キーが安全に保存され、第三者による読み出しが不可能であることも保証されなければならない。後者の機能性はウェブセントリー（ＷｅｂＳｅｎｔｒｙ）の暗号カードによって保証される。
・内容の保全性：第三者がキーの一部を偽造することが可能であってはならない。
・認証：双方の通信パートナーは差出人／受取人の認証が正しいことを確認しなければならない。受取人の見地からは、これはキーが郵便料金ポイントにおいて生成されたということを意味する。差出人の見地からは、正当なＺｉｎＳローカル暗号システムのみがキーを受信できることが保証されなければならない。
【００４６】
提示された対称型の方法において、双方の通信パートナーは同一のキーＫＴを持つ。値転送センター（郵便料金ポイント）はキーＫＴを用いて、伝達されるデータキーＫＤを暗号化し、それからデータキーＫＤを支払保証システム（ＺｉｎＳセントラルシステム）のサーバーへと転送する。
【００４７】
それからこのキーをさらに中央支払保証システムから局所支払保証システムのＺｉｎＳローカル暗号システムへと移送する。これらのシステムもキーＫＴにアクセスし、それによってキーＫＤを再び解読できる。キーＫＤを移送の間に安全に防御するためにキーＫＴを用いるので、キーＫＴも以下において移送キーと呼ぶ。
【００４８】
全ての局所支払保証システムが同じデータを受信するので、個々の局所暗号サーバーと値転送センター（郵便料金ポイント）との間で別々の移送キーＫＴを定義する必要がない。しかし、安全性の理由から、このキーＫＴはデータキーＫＤのように一定の間隔で更新するべきである。しかし、キーＫＤではあまり多くのテキストを暗号化しないので、交換の間隔は長くすることができる。１年または２年の交換間隔が、ここでは特に有利である。
【００４９】
この方法の不可欠な構成要素は移送キーＫＴの置換であり、これは安全性の理由から、データキーＫＤの置換と同じチャンネルで行うべきではない。この置換は手動では行わない。この手続きは複数の局所支払保証システムについて一定間隔で行わなければならないので、移送キーの置換も自動化できるように、ここで別の手法を提供しなければならない。
【００５０】
この目的のために、ＡＮＳＩ規格Ｘ９．１７（金融サービスのための対称手法に基づいたキー管理）において、マスター移送キー（以下、ＫＴＭと呼称）と呼ばれる別のキーレベルが定義されている。このキーは特別な安全性警戒の元で暗号カードにインストールしなければならず、また拡大した間隔において置換しなければならない。ここで、全てのシステムに同じＫＴＭがインストールされる。それからこのキーで移送キーＫＴを暗号化し、その後キーＫＴを同じチャンネルによって自動化された様式で配布し、受け入れを行う。該配布はデータキーの配布と同様に行われる。個別のシステムまたはその暗号カードの初期化については以下の節で詳述する。
【００５１】
メッセージの保全性と差出人（郵便料金ポイント）の認証を保証するために、個別のキーメッセージにマトリクスコード（ＭＡＣ）が形成される。ＭＡＣの生成のために、ＫＴＭと同様に暗号カードの初期化の間に受け入れられる署名キーＫＳが必要となる。データキーメッセージの署名は、その後でこのキーＫＳによってなされる。ドイチェポストのイントラネット内での伝達の間におけるメッセージの機密性は、強い暗号手法を用いることでこのように確保される。メッセージの暗号化と解読の特に好ましい手法はトリプルＤＥＳ（キー長１６８ビット）である。ハッシュ値はＳＨＡ−１アルゴリズムによって計算することが好ましい。
【００５２】
郵便料金ポイントと支払保証システムの暗号システムに存在する正当性の様々な周期を、データキーの配布と保存のために考慮しなければならない。最大２つのキーＫＤが所定の時間において郵便料金ポイントで利用可能でなければならない。つまり、１つのキーは現在正当であり、新たに生成された郵便料金額を伴うもう１つのキーは暗号化される（ＫＤｎｅｗ）。
【００５３】
該キー（ＫＤｎｅｗ）による既存のキーの操作の‘置換’モードにおいて、新たなキーが支払保証システムの暗号システムに伝達される。このキーを全ての局所支払保証システムの暗号システムに受け入れ成功してから、ＺｉｎＳセントラルシステムの放出メッセージが生成され、この時点において、ＫＤｎｅｗが郵便料金ポイントの新たな郵便料金額の暗号化に用いられる。この時点において、古いＫＤは郵便料金ポイントから消去すべきであり、またこれ以上新たな郵便料金額の生成に用いられるべきではない。
【００５４】
局所支払保証システムの暗号システムでは状況は異なる。ダウンロードされた郵便料金額は事前に定義できる時間の周期、例えば３ヶ月にわたって郵便証印の作成に使用でき、複数のキーＫＤが郵便証印の証明に利用可能でなければならない。
【００５５】
さらに、キーの配布の際には、暗号システムに受け入れられず郵便料金ポイントにおいて有効化できなかったキーに何があったのかも考慮すべきである。これらのキーを他の暗号システムに受け入れさせることが可能であり、原則の問題として、さらなる証明の間についても考慮すべきである。
【００５６】
ここで、キーの明瞭な更新と可能な最も単純なシステムのメンテナンスを許容する一様な状態に達するためには、以下のキー配布の手法の実行方法の形式が特に好ましい。
（ａ）データキーは暗号化された形式で、確定したキーＩＤ（キー位相表示）、不確定な生成カウンター、および正当先行データキーとともに伝達される。
（ｂ）値転送センター（郵便料金ポイント）からのデータキーの個々の伝達は、中央支払保証システムで確認メッセージによって確認されるべきである。
（ｃ）確認が正だった場合は、全ての局所支払保証システムへのデータキーの受け入れは成功していて、顧客はキーを利用してＰＣ料金納付を行うことができる。
この場合、生成カウンターは続くキーの伝達のたびに増加する。
（ｄ）確認が負だった場合は、全ての局所支払保証システムへのデータキーの受け入れは成功しておらず、値転送センターは顧客のシステムに郵便証印を作成させるべきではない。でなければ正当な郵便物が多量に転用される危険があるためである。
この場合、生成カウンターは続くキーの伝達のたびに増加しない。すなわち、先の伝達の値のままとなる。
（ｅ）確認がない場合は、その間、値転送センター（郵便料金ポイント）はこれ以上の中央支払保証システム（ＺｉｎＳセントラル）へのキー伝達が不可能となる。（このような試行は当然、支払保証システムによって却下されるが、値転送センター内で阻止すべきである）
（ｆ）延長された時間周期にわたって支払保証システムによる確認がない場合（タイムアウト超過）、値転送センター（郵便料金ポイント）はその直接あるいは間接のユーザーインターフェースによって警報を出すことができる。
（ｇ）暗号カードがデータキーを受信したらすぐに、最前の伝達としての同じ生成カウンター値を持つデータキー全てを消去する。これによって、エラーによる伝達が多数の場合、かつて暗号カードへの読み込みに成功したキーのみが消去される。トランザクションの安全なキー伝達が許容される。
（ｈ）局所支払保証システムの暗号カードにおいて、ルーチンが繰り返し、好ましくは定期的に、特には日毎に呼び出され、それは既に必要でなくなったデータキーを消去する。続くデータキーに関してＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性に保存された終了日付が現在のシステムデータより小さい際に、データキーは（（ｇ）や他の有利な実施例において）消去される。
（ｉ）先のキーの終了日付になると、（できるだけ短い）猶予期間が計画されるべきである。それは、局所支払保証システムの領域で確認されると、失効した郵便料金額とともに作成された郵便証印が、その正当性が終了した後でまださらに２日間正当だと認識されるためである。さらに、新たなデータキーの生成と放出のタイムラグも考慮しなければならない。
【００５７】
図２において現在のキーの管理の適用領域とその支払保証の領域における利用の概観が示される。さらに、適用の好ましい領域が提示される。
以下において適用例を詳述する。
【００５８】
続いて、前述のキー管理手法の詳細を提示する。
前述の適用は、暗号カードを用いる例によって提示する。
【００５９】
まず、値転送センターの領域において暗号カードを初期化する方法を提示する。
・製造業者の範囲においては、カードのインストールと設定、カードのファームウェアのアップロードはまだなされていない。ファームウェアの機能性は埋め込まれたコード（著作権のあるソフトウェアルーチン）によって拡張される。安全性の理由から、ＰＫＣＳ＃１１（公開鍵暗号基準）によるキールーチン（生成、消去等）はユーザーによって阻止されるべきである。これにより、カードにおいてより高いキーの安全性が保証される。
・（複数の暗号カードを有する）クラスターの定義。
・局所マスターキーＬＭＫの生成と保存。ＬＭＫは３つ以上の成分に配布されるべきであり、成分の２つは暗号サーバーカードの再形成または初期化に特に有利である。個々の成分はスマートカードにＰＩＮ防御によって書き込まれることが好ましく、そして安全性管理者はスマートカードを受け取る。なお、バックアップのスマートカードも作成すべきである。その後、ＬＭＫを前記のマスター移送キーＫＴＭとして用いる。
・ユーザー管理：デフォルトの安全性管理者の消去と、（スマートカードに基づく）必要な認証規則を含む安全性管理者の定義。
・初期の署名キーＫＳの生成、ＫＴＭによる暗号化（ラップ）およびファイルとしての保存。このファイルのディスケットへの後のコピーは可能とすべきである（ファイル／ディスケットへのアクセスは安全性管理者にのみ可能とすべきである）。
・最初の移送キーＫＴの生成、付随するキーメッセージの創作、およびメッセージのファイルへの保存とその後での該ファイルのディスケットへのコピー（アクセスは安全性管理者にのみ可能とすべきである）。
【００６０】
［移送マスターキーの生成］
新たな移送マスターキー（ＫＴＭ）は以下に述べる様式で生成することが望ましい。付随する確認カードの局所マスターキー（ＬＭＫ）をＫＴＭとして用いる。安全性の理由から、ＬＭＫは３つ以上の成分に分割されるべきであり、成分の２つ以上は再受け入れに必要である。
【００６１】
個別の成分をスマートカードに保存し、個々の安全性管理者はスマートカードを受け取り個々のＰＩＮによりその安全性を確保する。ＰＩＮの機密を維持しスマートカードを安全な場所に保存することで、権限のない者がそれらにアクセス可能となることを防ぐ。
【００６２】
移送マスターキーの実装のために、２つ以上のＬＭＫ成分（２つの異なる認可カードに関する）が存在することが好ましく、これによって二重制御原則の自動的な実装が実行される。
【００６３】
ＫＴＭはトリプルＤＥＳキーでなければならない。キーのＩＤ属性は型式識別および確定した数からなる。
型式識別：ＫＴ
確定した数：０１から９９
長さ：固定４バイトがＣＫ＿ＣＨＡＲ［ ］として保管される。
【００６４】
原則の問題として、認可された者のみがキーを置換可能であることを保証するために、様々な安全性機構が適している。しかし、以下で述べる署名キーを用いる実施例は、改竄操作に対する特に高い安全性をもたらすので、特に有利である。
【００６５】
署名キーはキーメッセージの保全性を保証する。これはまた、キーメッセージの差出人が郵便料金ポイントであるかどうかを確認するのにも利用できる。署名キーの生成は、スマートカードで登録された安全性管理者にのみ可能とすべきである。これは、ＴＲＵＥに設定された‘感受性’とＦＡＬＳＥに設定された‘抽出’の安全性属性を有し、キー平文がカード外部で発見されることを防ぐＴＤＥＳキーであるべきである。キーのＩＤ属性は型式識別および確定した数からなる。
型式識別：ＫＳ
確定した数：０１から９９
長さ：固定４バイトがＣＫ＿ＣＨＡＲ［ ］としてファイルされる。
【００６６】
キーは送出のためにＫＴＭでラップする必要があり、それからディスケット上にファイルとして保存される。ディスケットは安全な場所に置かねばならず、暗号カードの初期化に用いる。キーファイルの保全性は、好ましくはラップに用いるカードに保存される、処理ルーチンによって保証される。
【００６７】
移送キーＫＳの好ましい属性は以下の表に編集される。
【００６８】
【表１】
【００６９】
ＬＡＢＥＬ属性の乱数は暗号サーバーカードへの受け入れ成功の確認に用いられる。ハッシュ値（例えばＳＨＡ−１による）はこの乱数のために形成され、受け入れ成功の確認と移送キーの放出のために用いられる。
【００７０】
ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲとしてファイルされる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００７１】
署名キーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化され、ＬＭＫのようにサイト上のハードウェアにアップロードされる。
【００７２】
移送キーの生成について以下で述べる。
この適用例においては、付随するキーメッセージを含む移送キーが生成される。
移送キーおよび／または付随するキーメッセージは安全性管理者によってのみ初期化可能なようにキー生成モジュールを設定することが好ましい。置換間隔は１年または２年とすべきである。
【００７３】
次に、移送キーは、以下の属性設定を備えるＴＤＥＳキーである。
【００７４】
【表２】
【００７５】
ＬＡＢＥＬ属性の乱数は暗号サーバーカードへの受け入れ成功の確認に用いられる。ハッシュ値（例えばＳＨＡ−１による）はこの乱数のために形成され、受け入れ成功の確認と移送キーの放出のために用いられる。
【００７６】
ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲとしてファイルされる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００７７】
移送キーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化され、値転送センターから中央支払保証システムへの伝達のために以下の構造を持つメッセージが形成される。
【００７８】
【表３】
【００７９】
さらなる配布に続いて、この移送キーメッセージはＺｉｎＳセントラルサーバーへと転送される。インターフェースはセッションビーンによって実現され、このサービスは指定のサービス（Ｊａｖａ Ｎａｍｉｎｇ ａｎｄ Ｄｉｒｅｃｔｏｒｙ Ｉｎｔｅｒｆａｃｅ−ＪＮＤＩ）によって調べられる。移送の手法は前記のデータブロックを要求すべきである。
【００８０】
さらに、メッセージを郵便料金ポイントにファイルとして保存し、安全性管理者はこれを後で、安全な場所に保存される１つ以上のディスケットに保存することができる。ディスケットはそれから暗号サーバーカードの初期化に用いられる。
【００８１】
移送キーの放出の好ましい実施例を以下に説明する。
値転送センターは移送キーＫＴを放出可能に設定される。移送キーＫＴの放出のために、全ての局所支払保証システム（ＺｉｎＳ暗号システム）への配布と受け入れが成功した移送キーを中央値転送センターから放出可能なインターフェースがある。放出によってのみ、付随する移送キーが続いてデータキー（ＫＤ）の暗号化に用いられる。
【００８２】
前記インターフェースはセッションビーンとして実現される。このサービスは指定のサービスによって調べられる。
放出手続きのデータ構造は以下のパラメータを有することが好ましい。
【００８３】
【表４】
【００８４】
ＰＰキー管理システムに対する支払保証システムのキー割り当てシステム（ＺｉｎＳキー管理システム）の認証はパラメータ２で行われる。これはＳＨＡ−１の手法を用いて移送キーのＬＡＢＥＬ属性から形成されるハッシュ値である。ＬＡＢＥＬ属性は移送キーの生成の際に乱数で埋められる。移送キーとその全ての属性は伝達の間に暗号化されるので、ＺｉｎＳ暗号サーバーのみが正しいハッシュ値を計算できる。
【００８５】
伝達されたハッシュ値がＬＡＢＥＬ属性のために計算されたＫＴのハッシュ値と同一の場合、該ハッシュ値は郵便料金ポイントウェブセントリーモジュールに位置され、伝達された処理ステータスが真の場合、移送キーは有効化される。これは、続いてデータキーメッセージが移送キーを用いて暗号化されることを意味する。
【００８６】
処理が誤っている（伝達されたステータスが偽である）場合には、この適用例の変形が存在する。この場合、このキー生成とキー配布のためのステータスがプロトコル処理され、付随する移送キーはこれによって消去される。
【００８７】
新たなデータキーの生成の好ましい例を以下に示す。
この適用例においては、付随するキーメッセージを含むデータキーが生成される。キー割り当てシステムは、この動作が安全性管理者によってのみ初期化可能なように設定される。これは３ヶ月毎に行われるべきである。中央支払保証システム（ＺｉｎＳセントラルシステム）からフィードバック（放出またはエラー）が受信されておらず、データキーＫＤが流通している場合、フィードバックが受信されるまで新たなＫＤの生成は阻止される。
【００８８】
データキー（ＫＤ）は特定のマトリクスコード内容の暗号化を行い、また支払いが郵便サービス提供者になされていない場合は正当な郵便証印を作成できないことを保証する。このデータキーによってＺｉｎＳ暗号サーバーにおいてデジタル郵便証印が証明される。データキーは、ＰＫＣＳ＃１１機能Ｃ＿ＧｅｎｅｒａｔｅＫｅｙを用いて生成され以下の属性を持つＴＤＥＳキーと同様である。
【００８９】
【表５】
【００９０】
ＣＫＡ＿ＩＤ属性の値と生成カウンターはシステムに規定される。ＣＫＳ＿ＩＤは上方へ１ずつカウントされるが、生成カウンターはキーの放出が成功したときのみ増加する。ＣＫＡ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性はＣＫ＿ＣＨＡＲ ［ ］として埋められる。全てのさらなる属性はｐｋｃｓ１１．ｈファイルによって形式に定義される。
【００９１】
ＬＡＢＥＬ属性の乱数によって暗号サーバーカードへの受け入れの成功が確認される。この乱数のためにハッシュ値が（ＳＨＡ−１によって）形成され、移送キーの受け入れの成功の確認と放出に用いられる。
【００９２】
データキーの置換のためのメッセージの生成はいくらか複雑で、以下のシーケンスを含む。
【００９３】
１． データキーはＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化される。これには、キーの全ての属性（特にＣＫＡ＿ＥＸＴＲＡＣＴＡＢＬＥ＝ｆａｌｓｅ）が同時に暗号化され、解読の際に正しく再設定されるという利点がある。この暗号化されたバイトシーケンスを用いて、以下の構造を持つ仮のメッセージが形成される。
【００９４】
【表６】
【００９５】
２． 次に、仮のメッセージは有効な移送キーＫＴによって、ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構を用いて暗号化される（初期化ベクターはゼロで埋める）。
【００９６】
３． 配布されるメッセージを形成し、それは以下の構造を有するものとする。
【００９７】
【表７】
【００９８】
４． その後、データキーメッセージをＺｉｎＳセントラルサーバーへのさらなる配布のために転送する。さらに、安全性管理者によって１つ以上のディスケットに保存し、それを安全な場所に保管して、新たなＺｉｎＳ暗号カードの初期化に使用できるようにする。
【００９９】
メッセージ内容の二重暗号化の利点は、暗号化の少ないテキストはインターネット経由でＫＴＭに伝達しなければならず、したがってこのキーの暗号解析がはるかに困難になる、ということである。
【０１００】
データキーＫＤの放出のために、インターフェースとプロトコル機構を設け、データキーの放出をプロトコル処理する。データキーの局所支払保証システムへの配布と受け入れの成功の後にのみデータキーを放出するように中央支払保証システムを設定することが好ましい。この放出によってのみ、付随するデータキーは続いて暗号文字列の暗号化に用いられ、郵便証印に組み込まれ付随キー識別情報ＫｅｙＩＤを郵便料金額の識別情報（ＰｏｓｔａｇｅＩＤ）の中で暗号化する。
【０１０１】
インターフェースは中央支払保証システム（ＺｉｎＳセントラル）と局所支払保証システム（ＺｉｎＳローカル）との間のＣＷＭＳ（コンピューター作業管理システム）によって実現される。値転送センター（郵便料金ポイント）ＰＰは適切なビーンから情報を受信する。放出手続きのためのデータ構造は以下の内容を有する。
【０１０２】
【表８】
【０１０３】
値転送センターＰＰのキー割り当てシステムに対する、支払保証システムのキー割り当てシステムの認証は、パラメータ２によって行われる。これはＳＨＡ−１の手法を用いて移送キーのＬＡＢＥＬ属性から形成されるハッシュ値である。ＬＡＢＥＬ属性は移送キーの生成の際に乱数で埋められる。データキーとその全ての属性は伝達の間に暗号化されるので、支払保証システムの暗号サーバーのみが正しいハッシュ値を計算できる。
【０１０４】
伝達されたハッシュ値がＬＡＢＥＬ属性のために計算されたＫＤのハッシュ値と同一の場合、該ハッシュ値は郵便料金ポイントウェブセントリーモジュールに位置され、伝達された処理ステータスが真の場合、移送キーは有効化される。これは、続いて郵便証印／郵便料金額のための暗号文字列がこのデータキーを用いて暗号化されることを意味する。データキーが有効化されると、署名キーの生成カウンターが１つずつ増加する。
【０１０５】
処理が誤っている（伝達されたステータスが偽である）場合、この適用例の変形が存在する。この場合、このキー生成とキー配布のためのステータスがプロトコル処理され、付随する移送キーはカードから消去される。この場合、署名キーの生成カウンターが１つずつ増加することはない。
【０１０６】
キー割り当てシステムは実行されたキー生成を保存するステータスメモリーを有することが好ましい。実行されたキー生成のついて中央支払保証システム（ＺｉｎＳセントラルシステム）からのフィードバックが受信されていないと、ステータスが開いて表示される。フィードバックと配布が成功すると、有効化されているとしてキーが指定される。エラーの場合は、伝達されたステータスメッセージが表示される。エラーあるいは放出メッセージの不在が延長された場合、エラー調査ルーチンが呼び出される。
【０１０７】
キーをアーカイブすることが有利である。値転送センターの領域における好ましいキーのアーカイブについて以下で説明する。キーの安全性を保証するために、安全性管理者は全てのキー（ＫＴＭを除く）をＫＴＭ（ＬＭＫ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて暗号化して返送するアーカイブ機能を開始することができる。これらのキーはデータベースまたは安全ファイルシステム領域に安全に保存されるべきである。
アーカイブの成功の後で、初期正当性日付を６ヶ月以上過ぎて既に有効でない全てのキーが消去される。
【０１０８】
特に値転送センターＰＰの領域において、キーは復旧され、アーカイブされたキーデータは解読され（ラップを解かれ）カードに保存される。ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構が再び用いられる。
キーが解読された後で、既にカードに存在していた同一のキー識別情報ＫｅｙＩＤを有するキーは消去される。
【０１０９】
ウェブセントリーカードの特別な安全性手段と複数のスマートカードへの配布によって、マスター移送キーＫＴＭは漏洩に対し確実に安全性を保証される。
にもかかわらずマスター移送キーの置換がなされる場合は、“暗号カード”（ＰＰ）の初期化を含む適用例と同様に、新たなＫＴＭと新たな署名キー、移送キーおよびデータキーを生成しなければならない。
先のＫＴＭはいわゆる“潜在ＬＭＫ”としてカードに残され、安全性管理者によって適当に消去されなければならない。
【０１１０】
キー割り当てシステムの好ましい適用例を以下で説明する。提示は支払保証システムの全ての領域に適用される。これは特に個別の構成要素が、好ましくは局所支払保証システムまたは中央支払保証システムの領域に実装される場合に有利である。しかし、他の支払保証システムにおける使用も同様に可能である。
【０１１１】
第１の適用例は支払保証システムの領域における暗号カードの初期化である。
暗号カードの初期化のために以下の基本的な設定が用いられ、機能性の大半は管理ツール（ウェブセントリーマネージャー（ＷｅｂＳｅｎｔｒｙＭａｎａｇｅｒ））で管理できる。
・製造業者が既に行っていない範囲での、暗号カードのインストールと設定、カードファームウェアのアップロード。ファームウェアは埋め込まれたコード（著作権のあるソフトウェアルーチン）を有する。（後の機能性はウェブセントリーマネージャーに統合される）
・クラスターの定義づけ（複数の暗号カードを用いる）（ウェブセントリーマネージャー）
・移送マスターキー（ＫＴＭ）の受け入れ、分離適用例を参照（機能性はウェブセントリーマネージャーによって提供される）
・ユーザー管理：デフォルトの安全性管理者の消去と、（スマートカードに基づく）必要な認証規則を含む安全性管理者の定義
あらかじめ定義されたＰＩＮによって認可される、２つの“通常”ユーザーの生成（１つはキー証明のため、もう１つはキー受け入れのため）
ユーザー管理の機能性は同様にウェブセントリーマネージャーによって提供される。
・署名キー（ＫＳ）の受け入れ：分離適用例を参照
・移送キー（ＫＴ）の受け入れ：分離適用例を参照
・随意のデータキー（ＫＤ）の同様な受け入れ：（同様にその適用例を参照）すでに生成された範囲内
【０１１２】
キーは以上で定義したシーケンスにおいて受け入れられなければならない。カードは中央において初期化可能で、完全な暗号システムコンピューターを初期化し、その後送らなければならない。これはウェブセントリーカードがＰＣＩスロットから引き抜かれるとすぐに内部の記憶を消去するからである。
【０１１３】
暗号システムに対しスマートカードリーダーと関連したスマートカードで局所的に識別された２人以上の安全性管理者によってのみ、移送マスターキーを受け入れることが可能であることが好ましい。キーＫＴＭの重要性のために、このキーは二重制御原理を用いてのみカードに受け入れ可能とする。これは適用例“移送マスターキー”において生成された２つ以上のＰＩＮ防御スマートカードが受け入れに必要であることを意味する。
【０１１４】
マスター移送キーＫＴＭは双方のスマートカードを用いてのみ読み込み可能で、キーの使用はＰＩＮ防御されているため、このキーは二重制御原理を用いてのみカードにインストール可能であることが保証される。これによって違法なキーに対し非常に高い水準の防御を提供できる。
【０１１５】
この機能性は管理ツール、ウェブセントリーマネージャーによって提供される。この管理ツールによって、いわゆる局所マスターキー（ＬＭＫ、この構想において述べられたＫＴＭに対応）をスマートカードから読み出し、カードの安全な保存領域に保存することが可能となる。
【０１１６】
ＬＭＫを３つのスマートカードに配布することが特に有利であり、ＬＭＫを暗号ハードウェアに受け入れるために全ての３つの部分が必要である。この場合、マスター移送キーＫＴＭの受け入れのために３人の安全性管理者が必要である。
【０１１７】
署名キーはキーメッセージの保全性を保証する。これはまたキーの受け入れの前に、キーメッセージの送信者が値転送センター（郵便料金ポイント）であるかどうかを決定することにも使用できる。署名キーは異なる方法で生成することが可能で、ここで提示する例は特に有利なものである。付随キーメッセージは管理者によってディスケット上に保存され、この適用例では、初期化される支払保証システムの暗号カードに受け入れられる。
【０１１８】
キーの受け入れのために、ディスケット上に保存されたキーメッセージをマスター移送キーＫＴＭ（ＰＫＣＳ＃１１機能Ｃ＿Ｕｎｗｒａｐ、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）を用いて解読する。キーメッセージの保全性はこのルーチンによって自動的に確認される。このキーＩＤを持つキーが既に存在している場合は、続いて削除される。
【０１１９】
移送キーメッセージのさらなる移送のために、中央支払保証システムのサーバーにインターフェースが設けられ、これによって配布とそれに続く個別の支払保証システムの暗号システムへの受け入れを初期化することができる。
【０１２０】
インターフェースはＲＭＩサービスによって実現される。このサービスは指定のサービス（ＪＮＤＩ）によって調べられる。配布はＣＷＭＳ（コンピューター作業管理システム）によって、Ｐ／Ｎリストの配布を用いてなされる。
【０１２１】
新たな配布ジョブが創作されると、キーメッセージは全ての現在登録されている暗号システムに転送され、個々の場合にプロトコルの入力が書き込まれる。暗号システムの管理は支払保証システムの適用例によってなされる。
【０１２２】
新たなキーメッセージの受信は個別の暗合システムにおいて受け入れ制御装置によって一定の間隔でなされる（配布機構の機能として）。新たなメッセージが受信されると、適用例“移送キーの受け入れ”が自動的に実行される。この動作の戻り値を確認する。負のフィードバックを受信した場合は、受け入れの試行を３回まで繰り返す。
【０１２３】
３回の試行の後でまだ受け入れが不可能な場合は、失敗に関するプロトコルメッセージをＺｉｎＳセントラルシステムに送信する（再び移転機構の機能として）。受け入れが成功した場合は、正のプロトコルメッセージが発行される。
プロトコルメッセージは適用例“プロトコルキー処理”によって中央で処理される。移送キーの放出も同様に開始される。
【０１２４】
移送キーの受け入れはサイト上の暗号システムを初期化する安全性管理者によって実行されるか、あるいはこの受け入れは受け入れ制御装置が新たな移送キーメッセージを受信した際に受け入れ制御装置によって自動的に開始されるものとする。キーは以下の処理手順によって受け入れられることが好ましい。
【０１２５】
１． カードへの登録はキー受け入れユーザーに属するＩＤとＰＩＮによってなされる。
【０１２６】
２． ハッシュ値はＳＨＡ−１手法を用いて移送キーのフィールド１から５へと形成される。
【０１２７】
３． 署名キーがフィールド４に表示されるキーＩＤを有していることを確認する。
【０１２８】
４． このキーは上記２で形成されたハッシュ値の暗号化に用いられ（ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）、フィールド６と比較される。これらの２つの値が合致すると、保全性が保証され、メッセージがＰＣ料金納付システムによって創作されたことが保証される。
【０１２９】
５． メッセージのフィールド５の内容はＫＴＭ（Ｃ＿ＵｎｗｒａｐＫｅｙ手法、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）によって解読される。結果、適当な移送キーオブジェクトが自動的に生成されカードに保存される。なお、該機構は再び暗黙のうちにキーの保全性と差出人の正確さを確認する。
【０１３０】
６． カードに同一のキーＩＤを持つキーが既に存在する場合、それは消去される。
【０１３１】
７． 新たに受け入れられたキーのＬＡＢＥＬ属性に、ハッシュ値がＳＨＡ−１手法を用いて形成され、これはキーＩＤおよび戻り値としての正のメッセージとともに返送される。
【０１３２】
８． ユーザーのセッションを終了する。
【０１３３】
９． プロトコルメッセージを戻り値から創作し、ＺｉｎＳセントラルシステムに送信する。
【０１３４】
１０． このキーＩＤのために保存されている失敗した試行がリセットされる。
【０１３５】
この適用例の変形は、ルーチンの１つまたはＭＡＣの確認の失敗である。この場合、さらなる処理は打ち切られ、キーＩＤ、エラーコードおよびエラーメッセージを含む戻り値が返送される。キーＩＤについて、保存されている失敗した試行の数が１つずつ増加する。この数が３に達すると、最も新しく転送された戻り値からプロトコルメッセージが創作され、中央支払保証システムに送信される。
【０１３６】
手動での初期化の場合、さらに受け入れの結果が安全性管理者のモニターに表示される。
手順２から７をカードソフトウェアにおいて直接実行することが好ましい（埋め込みコード）。これによって性能および違法に対する安全性が向上する。
【０１３７】
データキーメッセージのさらなる移送のために、中央支払保証システムのサーバーに、局所支払保証システムの個別の暗号システムへのデータキーの配布とそれに続く受け入れのための新たなインターフェースを設ける。
インターフェースはセッションビーンとして実現され、このサービスは指定のサービス（Ｊａｖａ Ｎａｍｉｎｇ ａｎｄ Ｄｉｒｅｃｔｏｒｙ Ｉｎｔｅｒｆａｃｅ−ＪＮＤＩ）によって調べられる。
【０１３８】
配布はＣＷＭＳ（コンピューター作業管理システム）によって、Ｐ／Ｎリストの配布を用いてなされる。
【０１３９】
新たな配布ジョブが創作されると、キーメッセージは全ての現在登録されている暗号システムに転送され、個々の場合にプロトコルの入力が書き込まれる。暗号システムの管理は支払保証システムの適用例によってなされる。値転送センターＰＰにおいてフィードバックが受信されておらず、データキーの配布ジョブが既に循環している場合は、フィードバックの時点までさらなるデータキーの配布ジョブの受容が拒否される。
【０１４０】
新たなキーメッセージの受信は個別の暗合システムにおいて受け入れ制御装置によって一定の間隔でなされる（配布機構の機能として）。新たなメッセージが受信されると、適用例“移送キーの受け入れ”が自動的に実行される。この動作の戻り値を確認する。負のフィードバックを受信した場合は、受け入れの試行を３回まで繰り返す。
【０１４１】
３回の試行の後でまだ受け入れが不可能な場合は、失敗に関するプロトコルメッセージをＺｉｎＳセントラルシステムに送信する（再び移転機構の機能として）。受け入れが成功した場合は、正のプロトコルメッセージが発行される。
プロトコルメッセージは適用例“プロトコルキー処理”によって中央で処理される。移送キーの放出もこの適用例によって開始される。
【０１４２】
移送キーの受け入れはサイト上の暗号システムを初期化する安全性管理者によって実行されるか、あるいはこの受け入れは受け入れ制御装置が新たな移送キーメッセージを受信した際に受け入れ制御装置によって自動的に開始されるものとする。
【０１４３】
データキーメッセージの特徴を考慮して、キーは移送キーの受け入れと同様にして受け入れられる。
【０１４４】
１． カードへの登録はキー受け入れユーザーに属するＩＤとＰＩＮによってなされる。
【０１４５】
２． ハッシュ値はＳＨＡ−１手法を用いて移送キーのフィールド１から７へと形成される。
【０１４６】
３． 署名キーはフィールド５に表示されるキーＩＤを有することを確認される。
【０１４７】
４． このキーは上記２で形成されたハッシュ値の暗号化に用いられ（ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）、フィールド８と比較される。これらの２つの値が合致すると、保全性が保証され、メッセージがＰＣ料金納付システムによって創作されたことが保証される。
【０１４８】
５． 署名キーはフィールド６に表示されるキーＩＤを有することを確認される。
【０１４９】
６． メッセージのフィールド７の内容を、５で確認されたキーによって解読する（Ｃ＿Ｄｅｃｒｙｐｔ手法、ＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤ機構、初期化ベクターＩＶはゼロで埋められる）。解読結果が仮のメッセージである。
【０１５０】
７． 仮のメッセージのフィールド１の内容はＫＴＭ（Ｃ＿ＵｎｗｒａｐＫｅｙ手法、ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ウェブセントリー機構）によって解読される。結果、適当な移送キーオブジェクトが自動的に生成されカードに保存される。なお、該機構は再び暗黙のうちにキーの保全性と差出人の正確さを確認する。
【０１５１】
８． カードに同一のキーＩＤを持つキーが既に存在する場合、それは消去される。
【０１５２】
９． 暗号カードの全てのデータキーを読み込み、ＬＡＢＥＬ属性の生成カウンターの値、バイト１が新たに受け入れられたキーと同一かを確認する。同一であれば、これらのキーをカードから除去する。別の局所支払保証システムの暗号システムへの受け入れにおけるエラーによって、これらのキーは値転送センターＰＰにおいて放出されなかった。
【０１５３】
１０． 新たに受け入れられたキーのＬＡＢＥＬ属性のバイト２から６５に、ハッシュ値がＳＨＡ−１手法を用いて形成され、これはキーＩＤおよび戻り値としての正のメッセージとともに返送される。
【０１５４】
１１． 暗号カードによるユーザーのセッションを終了する。
【０１５５】
１２． プロトコルメッセージを戻り値から創作し、ＺｉｎＳセントラルシステムに送信する。
【０１５６】
１３． このキーＩＤのために保存されている失敗した試行がリセットされる。
【０１５７】
この適用例の変形は、ルーチンの１つまたはＭＡＣの確認の失敗である。この場合、さらなる処理は打ち切られ、キーＩＤ、エラーコードおよびエラーメッセージを含む戻り値が返送される。キーＩＤについて、保存されている失敗した試行の数が１つずつ増加する。この数が３に達すると、最も新しく転送された戻り値からプロトコルメッセージが創作され、中央支払保証システム（ＺｉｎＳセントラルシステム）に送信される。
手動での初期化の場合、さらに受け入れの結果が安全性管理者のモニターに表示される。
【０１５８】
手順２から１０をカードソフトウェアにおいて直接実行することが好ましい（埋め込みコード）。これによって性能および違法に対する安全性（特に初期化ベクターＩＶおよびＫＴＭｓにおいて）が向上する。
データキーのクリーンアップは繰り返し、好ましくは定期的に、支払保証システムの可能な限り多くの、好ましくは全ての暗号システムにおいて行われ、これによって既に不要となったデータキーが消去される。
【０１５９】
［データキーのクリーンアップの手続き］
１． カード上の全てのデータキーＫＤを確認し、そのＩＤ（ＣＫＡ＿ＩＤ属性）によって確認順に分類する。
【０１６０】
２． このリストの各キーについて、以下の確認手続きを行う。
Ｉ． キーの後継を決定する（次に大きいＩＤ）。
ＩＩ． 存在する場合、以下を証明する。
（１） 前者の正当性の終了を示す後継のＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性が現在のシステム日付より小さいかどうか。小さい場合は、リストの現在処理されているキーを消去する。
（２） 後継の生成カウンター（ＣＫＡ＿ＬＡＢＥＬ属性のバイト１）が現在処理されているキーの生成カウンターと同一かどうか。同一の場合は、リストの現在処理されているキーを消去する。
【０１６１】
キー処理は中央支払保証システムのサーバー（ＺｉｎＳセントラルサーバー）においてプロトコル処理されることが好ましい。この適用例によってプロトコル処理されるキーは移送キーとデータキーである。
【０１６２】
個々の配布ジョブについて、キーメッセージが送信された有効な暗号システムを示すプロトコルが作成される。個々のシステムと配布ジョブについて、ステータス“送信済み”における最初のセットである分離入力が生成される。
個々のキー処理の成功および失敗の後に、個別の暗号システムはプロトコルメッセージを生成し中央支払保証システム（ＺｉｎＳセントラルシステム）に送信する。この配布はＪＭＳキューによって、あるいはデータベース複製によって行われる。
【０１６３】
中央支払保証システムの領域において、メッセージは受信された後で前記のプロトコル入力のアップデートに用いられる。この目的のために、ステータス“処理成功”／“失敗”および、あるいはエラーコードとメッセージもが保存される。
【０１６４】
プロトコルメッセージの処理に続いて、全ての暗号システムによって組み込みが成功した配布ジョブが存在するかどうかが確認される。存在する場合、特に値転送センターの領域内の、付随するキーの放出が初期化される。システムがエラーを報告したらすぐに、負の状態を持つ対応するエラーメッセージが値転送センターの領域内において生成される。
キー放出が呼び出されているという事実は配布ジョブによって注意され、これによって与えられたジョブに追加の放出は実行されない。しかし警告が長く入力されないほど、放出サービスへの接触の新たな試行が一定の間隔で行われる。
【０１６５】
定義された期間の後、好ましくは数日後、例えば３日後に、全ての暗号システムからのフィードバックが受信されない場合に、特別な変形が存在する。この期間の終了後に、負の放出メッセージが値転送センターに送信される。
【０１６６】
キー割り当てシステムが、管理者にキー配布ジョブのステータスを確認することを可能とするユーザーインターフェースを持つことが好ましい。個々の配布ジョブについて以下のデータが表示される。
・配布メッセージが送信されたシステムの数
・処理成功が報告されたシステムの数
・処理の結果が報告されていないシステムの数
・処理の失敗が報告されたシステムの数
【０１６７】
さらに、個々のシステムの現在のステータスが表示される詳細な表を作成可能である。
代替として、割り当てカード上に保存されるキーを局所的に表示することも可能である。
【０１６８】
配布ジョブを生成された全てのキーを中央支払保証システムの領域においてアーカイブすることが有利である。局所システムにおいてはアーカイブを行わないことが好ましい。ここで、キーはカードの不揮発性メモリーに保存する。同様に放出されたキーメッセージのみをアーカイブする。
【０１６９】
特定の暗号システムについて、移送キーおよびデータキーのキー復旧は中央で可能である。この場合、アーカイブからの現在のキーが確認され、特定の暗号システムへ送信される。この目的のために、プロトコルメッセージも同様に生成される。この形式のキー配布において、放出メッセージのみは存在しない。
【０１７０】
マスター移送キーＫＴＭが消失した場合、対応する暗号システムが新たな初期化のために安全性管理者への送信を行うか、あるいは安全性管理者がサイト上で各システムを初期化しなければならない。
【０１７１】
ウェブセントリーカードの特別な安全性手段、複数のスマートカードへの配布、および多段キーシステムによって、マスター移送キーＫＴＭは漏洩に対し確実に安全性を保証される。
しかし、マスター移送キーの置換が行われた場合は、新たなマスター移送キーＫＴＭおよび新たな署名キー、移送キー、データキーが生成されなければならない。
【０１７２】
これらを局所支払保証システムの全ての暗号システムへと受け入れなければならない。全ての暗号システムが中央管理サイトへの移送を行いこれを戻さなければならず、あるいは安全性管理者が局所支払保証システムの全てのサイトへ移動しなければならないので、これはより多くの労力を伴う。したがって、マスター移送キーＫＴＭについての本発明による安全性機構を利用することは特に有利である。
先のマスター移送キーＫＴＭはいわゆる”潜在ＬＭＫ“としてカード上に残り、これは安全性管理者によって適当に消去されなければならない。
【０１７３】
キーの取り扱いと解読は埋め込みコードとしてカード上に存在するべきである。この様式では、高い安全性が達成できるだけでなく暗号システムの性能向上が期待できる。
【０１７４】
暗号カードは提示された拡張とともに、下に列記した標準ＰＫＣＳ＃１１の機能を含むことが好ましい。
・Ｃ＿ＣｌｏｓｅＳｅｓｓｉｏｎ
・Ｃ＿ＧｅｔＳｌｏｔＬｉｓｔ
・Ｃ＿Ｉｎｉｔ
・Ｃ＿Ｉｎｉｔｉａｌｉｚｅ
・Ｃ＿Ｌｏｇｉｎ
・Ｃ＿Ｌｏｇｏｕｔ
・Ｃ＿ＯｐｅｎＳｅｓｓｉｏｎ
【０１７５】
さらに、恒常的に保存される機能はサードパーティーのさらなる拡張を含むべきではなく、ここで要求される拡張は支払保証システムの暗号カードの機能としてのみ統合される。
【０１７６】
ＰＫＣＳ＃１１ ＤＬＬの潜在キー取り扱い手法を指定するために、これらの手法に接頭辞を与える。この接頭辞はＣＥ＿として定義される。ここで、ＣＥは暗号の拡張（Ｃｒｙｐｔｏ Ｅｘｔｅｎｓｉｏｎ）を表す。
【０１７７】
各埋め込み手法は形式ＣＫ＿ＲＶの戻り値を供給し、これはｐｋｃｓ１１．ｈ包含ファイルの固定の構成要素として定義される。埋め込み手法の実装の間において、追加のエラー戻り値が定義され、統合のためのＣ＋＋ヘッダーファイル内に設けられる点で有利である。この方法は、埋め込み手法の呼び出しを通して、ハードウェア上に組み込まれた様々なＰｋｃｓ１１を呼び出せる点で有利である。ここでの別の利点は、暗号カードのソフトウェア内での完全に新しく確立されたキーの取り扱いである。
【０１７８】
［この手法の構文法を説明する例］
ＣＫ＿ＲＶ ＝ ＣＥ＿ＭｅｔｈｏｄＮａｍｅ （ｐａｒａｍｅｔｅｒ ｌｉｓｔ）
パラメータリスト内において、結果で埋められる必要のあるパラメータは参照による呼び出しによって転送される。手法の名前は有意味な語の組み合わせによって形成され、該手法が行うことの正しい意味を示す。
語の選択は内容を意味する関連付けを許容するように、例えば英語の技術用語の使用によってなされる。
【０１７９】
２つの計数形式の導入により、異なる埋め込み手法の機能性が証明される。キーの形式と属性について、該計数形式の間には相違がある。
ＣＥ＿ＥｎｕｍＫｅｙ ＝ ｛ ＣＥ＿ＫＴ， ＣＥ＿ＤＴ， ＣＥ＿ＳＥ， ＣＥ＿ＫＡ ｝
【０１８０】
ＣＥ＿ＫＡは特別な位置を仮定する。これは１つのキーではなく全てのキーのセットである。このＥｎｕｍＥｌｅｍｅｎｔが示されると、手法はカード内に含まれる全てのキーに関連する機能性を実装する。
ＣＥ＿ＥｎｕｍＫｅｙＡｔｔｒｉｂｕｔｅ ＝ ｛ ＣＥ＿ＩＤ， ＣＥ＿ＬＡＢＥＬ， ＣＥ＿ＳＴＡＲＴＤＡＴＥ， ＣＥ＿ＥＮＤＤＡＴＥ ｝
【０１８１】
必要な定義はｐｋｃｓ１１．ｈファイルへと引き継がれる。定義された拡張はｐｋｃｓ１１．ｈファイルに封入された分割ヘッダーファイル内に位置させることができる。埋め込み手法の実装のためには様々な機構が可能である。
【０１８２】
暗号環境において、関連する証明はそれに利用可能なＰＫＣＳ＃１１手法によって自律的に実行される。
ＣＫ＿ＲＶ ＣＥ＿Ｄｅｃｒｙｐｔ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ ［ ］ ｍｅｓｓａｇｅ， ＣＫ＿ＢＹＴＥ＊ ｐｏｓｔａｇｅＩＤ
ＣＫ＿ＢＢＯＯＬ ｂＯｋ）
【０１８３】
［機能の説明］
埋め込み暗号手法パラメータメッセージ内の５７バイトの長期の日付を受信し、この日付は郵便証印のマトリクスコードに対応する。以下の作業手順の説明における計数は１から始まる。
【０１８４】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターとして、最初の２バイトは０で埋められ、バイトｆ６からｆ１０およびｆ１４がマトリクスコードに付加される。
【０１８５】
［第２の手順：用いるＫＤの決定］
キー位相インジケーターはバイトｆ１４に含まれ、どのキーが用いられるかを表示する。キー位相インジケーターはＣＫＡ＿ＩＤキー属性内に保存され、キーを明白に識別する。以下で説明されるキーの取り扱いは効果的なキーの発見を可能とすべきである。
【０１８６】
［第３の手順：含まれる暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭにおいて使用される機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣである。バイトｆ１５からｆ３８の２４バイトが解読され、解読結果の最初の１２バイトがパラメータのＰｏｓｔａｇｅＩＤによって出力される。解読が成功すると、手順４あるいは手順５の手順が繰り返される。
【０１８７】
［第４の手順：ハッシュ値の形成とクリーンアップ］
特別に構成された７７バイトの大きいデータブロックが、日付のハッシュ値の形成の根拠となる。
バイト１から５３：マトリクスコードの最初の５３バイトに対応
バイト５４から６５：現在の暗号化されていないメッセージ部分（ＰｏｓｔａｇｅＩＤ）の最初の１２バイトに対応
バイト６６から７７：現在の暗号化されていないメッセージ部分の最後の１２バイトに対応
ハッシュ値はＳＨＡ−１を用いて形成され、この手続きの後で最初の４バイトがバイトｆ５４からｆ５７に一致しなければならない。一致しない場合、日付は正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順５となる。
【０１８８】
［第５の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
ＣＫ＿ＲＶ ＤＥ＿ＶｅｒｉｆｙＭｓｇ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ ［ ］ ｍｅｓｓａｇｅ， ｉｎｔ ｌｅｎｇｔｈ，
ＣＫ＿ＢＢＯＯＬ ｂＯｋ）
【０１８９】
証明手続きの一般的なデータブロックメッセージを以下に示す。
【０１９０】
【表９】
【０１９１】
未使用のフィールドはゼロで埋められる。手法の操作の様式はパラメータＭｓｇＴｙｐｅによって決定される。
生成されたデータブロックはＭｓｇＴｙｐｅのＫＴおよびＫＤへのメッセージに転送される。データブロックは個々の受信されたメッセージで埋められる。
【０１９２】
ＭｓｇＴｙｐｅのＫＴへの機能割り当てＣＥ＿ＶｅｒｉｆｙＭｓｇ ＫＴはＭＥＳＳＡＧＥ属性内の完全な移送キーメッセージ、およびＬＥＮＧＴＨ属性内のその長さを受信する。この埋め込みメッセージは受信者における移送キーメッセージの保全性を保証する。証明の動作のために、以下の手順を行う必要がある。
【０１９３】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターはゼロで埋められる。
【０１９４】
［第２の手順：受信した暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭで用いる機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤである。可変ＭＡＣフィールドのバイトが解読される。解読の間にエラーが起こった場合は、手続きは手順４となる。
【０１９５】
［第３の手順：ハッシュ値のクリーンアップ］
日付のハッシュ値の形成のために、移送キーメッセージのフィールド１＋２＋５＋６＋８からハッシュを形成し、これを手順２のハッシュと比較する。ＳＨＡ−１に使用するハッシュ値が形成される。ハッシュ値が同一でない場合は、日付が正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順４となる。
【０１９６】
［第４の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
【０１９７】
ＭｓｇＴｙｐｅ ＫＤについての機能割り当てＣＥ＿ＶｅｒｉｆｙＭｓｇの後で、ＭＥＳＳＡＧＥ属性内の完全な移送キーメッセージ、およびＬＥＮＧＴＨ属性内のその長さが転送される。この埋め込みメッセージは受信者における移送キーメッセージの保全性を保証する。証明の動作のために、以下の手順を行う必要がある。
【０１９８】
［第１の手順：初期化ベクターＩＶの形成］
初期化ベクターはゼロで埋められる。
【０１９９】
［第２の手順：受信した暗号化されたメッセージの解読］
ＣＫ＿ＭＥＣＨＡＮＩＳＭで用いる機構はＣＫＭ＿ＤＥＳ３＿ＣＢＣ＿ＰＡＤである。可変ＭＡＣフィールドのバイトが解読される。解読の間にエラーが起こった場合は、手続きは手順４となる。
【０２００】
［第３の手順：ハッシュ値のクリーンアップ］
日付のハッシュ値の形成のために、データキーメッセージのフィールド１＋２＋４＋３＋６＋７＋８からハッシュを形成し、これを手順２のハッシュと比較する。ＳＨＡ−１に使用するハッシュ値が形成される。ハッシュ値が同一でない場合は、日付が正当でない。ハッシングの実行の間にエラーが起きるか、あるいはハッシュ値に矛盾がある場合、手続きは手順４となる。
【０２０１】
［第４の手順：成功インジケーターの返送］
パラメータｂＯｋは、全ての作業手順が成功した場合は”真”で埋められ、ハッシュ値のクリーンアップが矛盾を示した、あるいはＰｋｃｓ＃１１手法の１つがエラーを起こしていた場合には“偽”で埋められる。戻り値はこのようにエラーメッセージ、あるいはエラーが起こっていない場合にはＣＫＲ＿ＯＫで埋められる。
【０２０２】
これらの埋め込みキー取り扱い手法はラップされたキーの受け入れおよび効果的なキー管理を含むべきである。形式ＫＳ、ＫＤおよびＫＴのキーが受け入れられるべきである。
ＣＫ＿ＲＶ ＣＥ＿ＩｍｐｏｒｔＫｅｙ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＫ＿ＢＹＴＥ＿ＰＴＲ ｄａｔａ，
ＣＫ＿ＵＬＯＮＧ ｌｅｎｇｔｈ， ＣＫ＿ＢＹＴＥ＊ ＨａｓｈＶａｌｕｅ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ＣＫ＿ＣＨＡＲ ［ ］ ＫｅｙＫＴＩＤ）
【０２０３】
機能割り当てＣＥ＿ＩｍｐｏｒｔＫｅｙは以下に述べるように行われることが好ましい。
ＣＫＭ＿ＫＥＹ＿ＷＲＡＰ＿ＷＥＢＳＥＮＴＲＹ機構がラッピングに用いられる。よって、ラッピングを解くためには同様の機構が必要である。得られたキーはラッピング解除によって暗号ハードウェアに受け入れられ、２回目に受け入れられたキー、つまり同一のキー位相を持つキーによって、古いキーが上書きされる。
【０２０４】
ラップされたキーはＤＡＴＡパラメータに転送され、ＬＥＮＧＴＨ属性内のその長さが転送される。キーの長さはキー属性の充填に依存する。キー形式はＫｅｙＴｙｐｅパラメータによって証明され、これによって処理される。
その後キーはキャッシュ操作内に保持されたキー管理に移され、利用可能であれば、複製の前者は消去される。
【０２０５】
ＫｅｙＫＴＩＤパラメータによって識別されたＫＴにより、ＤＴは解読され、他の全てのキー形式についてこのパラメータは考慮されず、ゼロで埋められる。
ＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性の従属は重要である。それは前者のキーの日付を示す。
【０２０６】
受け入れられたキーのキー属性は、それによってＳＨＡ−１を用いてハッシュ値を形成する乱数を含む。ハッシュ値は埋め込み手法のＨａｓｈＶａｌｕｅパラメータに戻される。ハッシュ値はキー確認メッセージに必要である。
【０２０７】
ラップ解除機構あるいはハッシュ形成の間のエラーにおいて、適当なエラーコードが戻り値あるいはＣＫＲ＿ＯＫに出力される。
ＣＫ＿ＲＶ ＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ｉｎｔ＊ ｃｏｕｎｔｅｒ）
【０２０８】
機能割り当てＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔは、個々のキー形式のキーがどれだけキャッシュ操作内のキー管理のカード上に登録されているかを示す。この様式においては、以下に述べる手法によってキー属性を読み出すことができる。
この方法は以下のように定義される。
ＣＫ＿ＲＶ ＣＥ＿ＧｅｔＡｔｔｒｉｂｕｔｅ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ＣＥ＿ＥｎｕｍＫｅｙＡｔｔｒｉｂｕｔｅ ＫｅｙＡｔｔｒｉｂｕｔｅ，
ｉｎｔ ｐｏｓ，
ＣＫ＿ＢＹＴＥ ［ ］ ＊ ａｔｔｒｉｂｕｔｅ，
ｉｎｔ＊ ｌｅｎｇｔｈ）
【０２０９】
キー形式はＫｅｙＴｙｐｅパラメータと、キーの形式によって暗号ハードウェア上の異なるキー形式が異なるリストに記録されるときに読まれる表によって決定される。
【０２１０】
ＫｅｙＡｔｔｒｉｂｕｔｅパラメータによって読み出される属性が指定され、ＩＴＥＭパラメータによって表の中の始点が示される。最初にその最大値を、全てのキーあるいは１つのキー形式についてＣＥ＿ＧｅｔＫｅｙＣｏｕｎｔ手法を用いて獲得しなければならない。ＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性が出力されると、最後の現在のキーが（同じ形式の新たなキーが受け入れられるまで）理論上無限に正当であり、またそのＣＫＡ＿ＥＮＤ＿ＤＡＴＥ属性において同一のキー形式の前者のキーの終了日付を含み、そしてこの示されたキーのＣＫＡ＿ＥＮＤ＿ＤＡＴＥが出力される。
【０２１１】
日付についての属性は８バイトの固定された長さを有するのに対し、ＣＳＫ＿ＩＤおよびＣＫＡ＿ＬＡＢＥＬ属性は１２８バイトの固定された長さを有する。これらの２つのパラメータについてのキー内の属性が１２８バイトより短い場合は、１２８までの残りのバイトは０で埋められる。したがって、ユーザーは常に当該の手法に充分なメモリーを提供できる。ユーザーの提供するバッファーが小さすぎる場合は、情報はトリミングされ、この結果のメッセージがＣＫ＿ＲＶによって伝達される。
ＣＫ＿ＲＶ ＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓ （ＣＫ＿ＳＥＳＳＩＯＮ＿ＨＡＮＤＬＥ ｓｅｓｓｉｏｎ，
ＣＥ＿ＥｎｕｍＫｅｙ ＫｅｙＴｙｐｅ，
ｉｎｔ＊ ｃｏｕｎｔｅｒ）
【０２１２】
機能割り当てＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓはカード内の失効したキーを探し、これをカードから消去する。失効したキーはシステム日付が後継のキーのＣＫＡ＿ＥＮＤ＿ＤＡＴＥ（２．５．８参照）より古いことによって識別され、これはＫＴおよびＫＳにも適用される。選択的消去はＥｎｕｍＴｙｐｅによって可能となり、ＣＥ＿ＫＡによってカード全体を消去できる（ＬＭＫのみ保持される）。この手法はキーの受け入れの実行の際には有効化を許容されないことが重要である。これは埋め込みコード内で制御され、適当な戻り値で示されることが好ましい。この方法により、内部キー管理において不確定な副作用が回避される。
サイドチャネルからの改ざんの可能性を除外するために、支払保証システムと値転送センターとの間のインターフェースは厳密であることが好ましい。
【０２１３】
値転送センター（郵便料金ポイント）と中央支払保証システムとの間のインターフェースの構造を図３に示す。
値転送センター（郵便料金ポイント）のＫｅｙＭａｎａｇｅｍｅｎｔ構成要素において生成されるキーが支払保証システムの暗号システムに配布可能であることにより、キー配布のためのインターフェースが中央支払保証システムに設けられる。
キーの配布成功と処理の後で支払保証システムがキーを放出可能であることにより、値転送センターによって支払保証システムにキー放出インターフェースが設けられる。
【０２１４】
両計画において主にＪａｖａ（登録商標）を用いているので、セッションビーンを用いる適用インターフェースの実現が推奨される。２つのシステムを分離するために、サービスはＪＮＤＩを用いて指定のサービスで調べるべきである。
【０２１５】
キーデータをＺｉｎＳセントラルシステムに受け入れるために必要な機能性がセッションビーンによって提供される。全体の通信は図４に示される。
データキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための処理手順が図４に示される。
【０２１６】
処理ルーチンＩｍｐｏｒｔＫｅｙによってデータキーセットがＺｉｎＳセントラルに転送される。
ＡＳＮ．１メッセージを使用することで、この処理ルーチンは受信メッセージを準備し、メッセージをデータベースに保存させる。処理ルーチンＩｍｐｏｒｔＫｅｙはそれからＣＷＭＳによるキーデータのＺｉｎＳローカルシステムへの配布を初期化する。
【０２１７】
データのデータベースへの受け入れシーケンスとそれに続くメッセージの配布は監視されるべきである。これによって受信されたデータが作業の前に安全性を保証される。この方法の利点は、エラーの領域のイベントをよりよく再構成でき、データの消失の場合には必要ならデータベースにアクセスできることである。
【０２１８】
この時点においてＡＳＮ．１フォーマットがサポートされているかが不明瞭なので、ＩｎｓｅｒｔＫｅｙＤａｔａ手法のパラメータはまだ指定されていない。しかし、詳細なメッセージを郵便料金ポイントにも送信可能とするためには２つのパラメータが装備されなければならないであろう。
【０２１９】
ＺｉｎＳセントラルにおいて、キー割り当てシステムの配布手法は下記の原因となる。
【０２２０】
１． ＺｉｎＳセントラルサーバー上でのキーメッセージのアーカイブ。
【０２２１】
２． ＶｉｂｒｉｓによるＣＷＭＳインターフェースによる、郵便料金ポイントから個別のメールセンターへのキーメッセージの配布。ＣＷＭＳの構造と利用はこのインターフェースの説明書に見られる。
【０２２２】
３． 個々のメールセンターへの配布と受け入れが完了した後に、付随する返送メッセージを生成する。
【０２２３】
データは値転送センター（郵便料金ポイント）からＡＳＮ．１フォーマットで伝達される。付随する応答も同様にＡＳＮ．１フォーマットと予想される。しかし、このフォーマットの代わりに他のフォーマットを用いることももちろん可能である。特定のフォーマットは適当なパーサーによって使用のために適用される。
ＡＳＮ．１の好ましいデータフォーマットは以下のものである。
【０２２４】
［移送キーの配布メッセージ］
ＴｒａｎｓｐｏｒｔＫｅｙＭｅｓｓａｇｅ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＭｓｇＴｙｐｅ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ｆｉｘ ‘ＫＴ’ ）
Ｖｅｒｓｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ）
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ）
ＳｉｇＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＳｉｇｎａｔｕｒｅＫｅｙ ｕｓｅｄ ｆｏｒ ＭＡＣ ）
ＴｒａｎｓＫｅｙＥｎｃｒｙｐｔ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＴｒａｎｓｐｏｒｔＫｅｙ ｗｒａｐｐｅｄ ｗｉｔｈ ＬＭＫ ）
ＭＡＣ ＯＣＴＥＴ ＳＴＲＩＮＧ （ ＭＡＣ ｏｖｅｒ ａｌｌ ｐｒｅｖｉｏｕｓ ｅｌｅｍｅｎｔｓ ）
【０２２５】
［データキーの配布メッセージ］
ＰｏｓｔａｇｅＫｅｙＭｅｓｓａｇｅ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＭｓｇＴｙｐｅ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ｆｉｘ ‘ＫＤ’ ）
Ｖｅｒｓｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ）
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ）
ＫｅｙＧｅｎｅｒａｔｉｏｎ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ０ｘ０１ ａｓｃｅｎｄｉｎｇ ）
ＳｉｇＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＳｉｇｎａｔｕｒｅＫｅｙ ｕｓｅｄ ｆｏｒ ＭＡＣ）
ＴｒａｎｓＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ＴｒａｎｓｐｏｒｔＫｅｙ ）
ＤａｔａＫｅｙＥｎｃｒｙｐｔｅｄ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＰｏｓｔａｇｅＫｅｙ ｗｒａｐｐｅｄ ｗｉｔｈ ＬＭＫ
ａｎｄ
ｅｎｃｒｙｐｔｅｄ ｗｉｔｈ ＴｒａｎｓｐｏｒｔＫｅｙ ）
ＭＡＣ ＯＣＴＥＴ ＳＴＲＩＮＧ （ ＭＡＣ ｏｖｅｒ ａｌｌ ｐｒｅｖｉｏｕｓ ｅｌｅｍｅｎｔｓ ）
｝
Ａｌｓｏ ｓｅｅ ｓｅｃｔｉｏｎ ２．４．６．
【０２２６】
［放出メッセージ］
ＫｅｙＥｘｃｈａｎｇｅＲｅｃｅｉｐｔ ：：＝ ＳＥＱＵＥＮＣＥ
｛
ＫｅｙＩＤ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＣＫＡ＿ＩＤ ｏｆ ｒｅｃｅｉｖｅｄ ｋｅｙ ）
ＫｅｙＬａｂｅｌＨａｓｈ ＯＣＴＥＴ ＳＴＲＩＮＧ， （ ＳＨＡ−１ ｈａｓｈ ｏｆ ＣＫＡ＿ＬＡＢＥＬ ｏｆ ｒｅｃｅｉｖｅｄ ｋｅｙ ）
Ｓｔａｔｅ ＢＯＯＬＥＡＮ， （ ＴＲＵＥ／ＦＡＬＳＥ ｔｏ ｅｎａｂｌｅ／ｄｉｓｍｉｓｓ ｋｅｙ ）
Ｍｅｓｓａｇｅ ＯＣＴＥＴ ＳＴＲＩＮＧ （ Ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ ｓｕｃｃｅｓｓ／ｆａｉｌｕｒｅ ）
｝
【０２２７】
データ構造は異なるセットアップを持つことができる。しかし、考慮される全ての情報の伝達を許容し、また小さいデータの送信の労力の説明となるので、提示された実施例におけるセットアップは特に有利である。特に、データはＣＷＭＳによって、好ましくは郵便サービス提供者のメールセンター内にある、局所支払保証システムへと伝達される。
【０２２８】
ＡＳＮ．１フォーマットが用いられる場合、データはまず内部キーメッセージに解析されなければならず、このドキュメント内に定義されるメッセージが直接使用される場合にはそれは不要となる。
【０２２９】
ＣＷＭＳによって受信されるデータパケットは、以前にこのドキュメント内に定義されたキーメッセージに対応する。これらのメッセージはそれから、最初にタイトル“データキーＫＤの属性”の上のデータ表に適合された後で、埋め込みコードのＶｅｒｉｆｙＭｓｇ手法に従属される。証明の後で、キーの受け入れが埋め込みコードによって開始され、あるいは適当なエラーメッセージが生成される。ＣＥ＿ＩｍｐｏｒｔＫｅｙ埋め込みコード手法における受け入れデータ構造の点において、キーメッセージとページ１２から１４を比較する。古いキーの消去と更新は前期の埋め込みコード手法によって自動的に行われ
【０２３０】
失効したキーを暗号ハードウェアから毎日除去するＣＥ＿ＤｅｌｅｔｅＥｘｐｉｒｅｄＫｅｙｓが毎日呼び出される事が必要である。受け入れの間に、複製キーが消去され新しいものと置き換えられることがＣＡ＿ＩｍｐｏｒｔＫｅｙ手法によって保証される。
埋め込みコード手法はＪａｖａ（登録商標）クラス ＣｒｙｐｔｏＡｄａｐｔｅｒｓによってアプリケーションに結び付けられる。ＣｒｙｐｔｏＡｄａｐｔｅｒｓは、埋め込みコードおよび他のＰＫＣＳ＃１１手法が提示する（同様に指定された）全ての手法を提示する。
【０２３１】
ＪＮＩによって、Ｚａｘｕｓに提供されるＤＬＬを静的に連結したＤＬＬ（ＣｒｙｐｔｏＡｄａｐｔｅｒ．ＤＬＬ）が用いられる。静的連結によって安全性リスクがさらに最小化される。
【０２３２】
ＪＮＩインターフェースのＣ＋＋実装によって、個々の要求されたセッションのエラーの取り扱いが提供される。これに関連してＰＣＦＭデザインドキュメントの“マルチスレッディング”下のステージ３を参照。暗号ハードウェアをマルチスレッディングモードにおいて初期化し、作業者がＤＬＬに登録されエラー取り扱いが作業者に特異的に確立された結果として、ログインの後で個々の作業者が自身のセッションを得る（ｇｅｔＳｅｓｓｉｏｎ， Ｃ＿ＧｅｔＳｅｓｓｉｏｎ）ことで、作業者の構想が支援される。ＤＬＬの本流はログインによって移動され、Ｐｋｃｓ＃１１手法および埋め込み手法の実行のためのエラー取り扱いを同様に有する。
【０２３３】
実装の概観を図６に示す。キーリスト、および埋め込み手法によって提供されるコードは除去される。あるいは、構造のセットアップは同一であるように選択されなければならない。
【０２３４】
［ＤＬＬの接続］
好ましい封入と有利なエラー取り扱いの例を図７に示す。
キーリストが暗号ハードウェアの埋め込みコードに完全に保持されている場合は、キーリストの実装は必要ない。ＧｅｔＡｔｔｒｉｂｕｔｅ手法は単一の埋め込みＣＥ＿ＧｅｔＡｔｔｒｉｂｕｔｅ手法に削減される。同じ理由で、受け入れのための呼び出しおよび実装も、必要なデータの転送の後で埋め込みコードによって自動的に行われるので削減される。
【０２３５】
拡張されたエラー定数リストが埋め込みコード内に設けられる。
郵便料金ポイントからのキーメッセージがＺｉｎＳセントラルのデータベースに保存され、欠陥のある局所支払保証システムの後での置き換えを可能としている。第一にそのようなメッセージをデータベースに組み込むことが要求され、第二に管理情報が受信される。
その結果、以下のデータベース表が必要となる。
【０２３６】
【表１０】
【０２３７】
郵便料金ポイントに受信されることでキーデータがキーメッセージを保存し、局所支払保証システムの不良の場合、キーメッセージのアーカイブによって、アーカイブされたキーを受け入れることで不良の局所支払保証システムが残りの局所支払保証システムと調整される。保存の前にメッセージをＡＳＮ．１によって解析し局所システムに伝達する必要がある。分割された形態のデータレコードは保存様式として好ましい。これは、ＣＥ＿ＶｅｒｉｆｙＭｅｓｓａｇｅ埋め込み手法に用いられるデータブロックを説明する表に対応する。
【０２３８】
【表１１】
【０２３９】
このデータレコードは重要性を有する。これは第一にメールセンター、好ましくは郵便サービス提供者の郵送システムに統合された全てのメールセンターの局所支払保証システムから受信されたフィードバックを評価するとともに、配布手続きの間に時間が超過すれば常に、可能なエラー解析およびシステムオペレータへの警告を行う。
【０２４０】
同じ理由で、この表は管理情報処理を要する。適用可能であれば、これは入力ＳＮＩｔｅｍＮｏを用いて付随するＴｒａｎｓｐｏｒｔＫｅｙＤａｔａおよび個別の（８３）メールセンターのＴｒａｎｓｐｏｒｔＫｅｙＲｅｐｌａｙＭｅｓｓａｇｅの割り当てと評価を可能とする。
【０２４１】
【表１２】
【０２４２】
この表において、局所支払保証システムの個別の応答メッセージは郵便サービス提供者のメールセンター内に受け入れ手続きの機能としてアーカイブされる。
【図面の簡単な説明】
【０２４３】
【図１】本発明によるキーの配布の特に好ましい実施例を示す図。
【図２】本発明によるキー配布システムの適用例を示す図。
【図３】中央支払保証システム（ＺｉｎＳセントラルシステム）と値転送センター（郵便料金ポイント）との間のインターフェースの概略図。
【図４】データキーの中央支払保証システム（ＺｉｎＳセントラル）への統合のための手順を示す図。
【図５】付随する暗号を含む、中央支払保証システム（ＺｉｎＳセントラルシステム）から局所支払保証システムへのキーの配布の概略図。
【図６】ＤＬＬインターフェースの接続状態を示す概略図。
【図７（Ａ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【図７（Ｂ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【図７（Ｃ）】コンポーネントの封入とエラーメッセージの取り扱いのための手順の概略図。
【特許請求の範囲】
【請求項１】
料金納付キーを用いて生成され郵便物に添付される郵便証印に含まれる暗号情報を解読して該郵便証印の信頼性の証明に用いる、郵便証印の信頼性の証明方法であって、
データキー（ＫＤ）が生成され中央支払保証システムから局所支払保証システムへと伝達されることを特徴とする方法。
【請求項２】
前記局所支払保証システムが前記データキーを受け入れ、受け入れの結果を前記中央支払保証システム（ＺｉｎＳセントラルシステム）に伝達することを特徴とする、請求項１に記載の方法。
【請求項３】
前記の受け入れの結果をデータレコードとして伝達することを特徴とする、請求項２に記載の方法。
【請求項４】
前記データレコードがキーを含むことを特徴とする、請求項３に記載の方法。
【請求項５】
前記中央支払保証システム（ＺｉｎＳセントラルシステム）が前記の受け入れの結果を確認し、これを値転送センター（郵便料金ポイント）に伝達することを特徴とする、請求項２から４のうち１つ以上に記載の方法。
【請求項６】
前記結果を前記キーの解読によって確認することを特徴とする、請求項５に記載の方法。
【請求項７】
事実上全ての前記局所支払保証システム（ＺｉｎＳローカル）への前記データキーの受け入れが成功してから、該データキーを前記値転送センター（郵便料金ポイント）において放出し、続いて新たな郵便料金額の生成に用いることを特徴とする、請求項１から６のうち１つ以上に記載の方法。
【請求項８】
前記データキーが対称キーであることを特徴とする、請求項１から７のうち１つ以上に記載の方法。
【請求項９】
新たなデータキーが前記値転送センター（郵便料金ポイント）から前記中央支払保証システムへと伝達されることを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１０】
前記値転送センターにおいて前記データキーを移送キー（ＫＴ）によって暗号化することを特徴とする、請求項９に記載の方法。
【請求項１１】
前記移送キーをマスター移送キー（ＫＴＭ）によって暗号化することを特徴とする、請求項１０に記載の方法。
【請求項１２】
前記データキーを前記値転送センターの領域内で生成することを特徴とする、請求項９に記載の方法。
【請求項１３】
前記データキーがキー識別情報を有することを特徴とする、請求項９に記載の方法。
【請求項１４】
前記キー識別情報が暗号化された形式で伝達されることを特徴とする、請求項１３に記載の方法。
【請求項１５】
前記データキーが生成カウンターを有し、さらに／あるいは該生成カウンターとともに伝達されることを特徴とする、請求項９から１４のうち１つ以上に記載の方法。
【請求項１６】
前記データキーを暗号要素、特に暗号カードへと伝達し、該暗号要素がデータキーを受信したらすぐに、伝達されたデータキーと同一の生成カウンター値を有するデータキー全てを消去することを特徴とする、請求項９に記載の方法。
【請求項１７】
前記データキーが先行するデータキーのための終了日付を有し、さらに／あるいは該終了日付とともに伝達されることを特徴とする、請求項９から１６のうち１つ以上に記載の方法。
【請求項１８】
前記料金納付キーを暗号要素に伝達し、該暗号要素が他のデータキーが終了日付を有するかどうか、および先行するデータキーのために保存されている該終了日付が前記支払保証システムに保存されている日付より古いかどうかを確認することを特徴とする、請求項１７に記載の方法。
【請求項１９】
前記データキーあるいは少なくとも該データキーの一部が郵便証印の生成のための料金納付キーの構成要素を形成することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【特許請求の範囲】
【請求項１】
料金納付キーを用いて生成され郵便物に添付される郵便証印に含まれる暗号情報を解読して該郵便証印の信頼性の証明に用いる、郵便証印の信頼性の証明方法であって、
データキー（ＫＤ）が生成され中央支払保証システム（ＺｉｎＳセントラル）から局所支払保証システム（ＺｉｎＳローカル）へと伝達され、後者に受け入れられ、受け入れの結果を該中央支払保証システム（ＺｉｎＳセントラル）に伝達するとともに、事実上全ての前記局所支払保証システム（ＺｉｎＳローカル）への該データキー（ＫＤ）の受け入れが成功してから、該データキー（ＫＤ）を新たな郵便料金額の生成のために放出することを特徴とする方法。
【請求項２】
前記データキーが先行するデータキーのための終了日付を有し、さらに／あるいは該終了日付とともに伝達されることを特徴とする、請求項１に記載の方法。
【請求項３】
前記料金納付キーを暗号要素に伝達し、該暗号要素が他のデータキーが終了日付を有するかどうか、および先行するデータキーのために保存されている該終了日付が前記支払保証システムに保存されている日付より古いかどうかを確認することを特徴とする、請求項２に記載の方法。
【請求項４】
前記データキーが生成カウンターを有し、さらに／あるいは該生成カウンターとともに伝達されることを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項５】
前記データキーを暗号要素、特に暗号カードへと伝達し、該暗号要素がデータキーを受信したらすぐに、伝達されたデータキーと同一の生成カウンター値を有するデータキー全てを消去することを特徴とする、請求項４に記載の方法。
【請求項６】
前記の受け入れの結果をデータレコードとして伝達することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項７】
前記データレコードがキーを含むことを特徴とする、請求項６に記載の方法。
【請求項８】
前記の受け入れの結果を値転送センター（郵便料金ポイント）に伝達することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項９】
前記結果を前記キーの解読によって確認することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１０】
事実上全ての前記局所支払保証システム（ＺｉｎＳローカル）への前記データキーの受け入れが成功してから、該データキーを前記値転送センター（郵便料金ポイント）において放出することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１１】
前記データキーが対称キーであることを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１２】
新たなデータキーが前記値転送センター（郵便料金ポイント）から前記中央支払保証システムへと伝達されることを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１３】
前記値転送センターにおいて前記データキーを移送キー（ＫＴ）によって暗号化することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１４】
前記移送キーをマスター移送キー（ＫＴＭ）によって暗号化することを特徴とする、請求項９に記載の方法。
【請求項１５】
前記データキーを前記値転送センターの領域内で生成することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１６】
前記データキーがキー識別情報を有することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１７】
前記キー識別情報が暗号化された形式で伝達されることを特徴とする、請求項１６に記載の方法。
【請求項１８】
前記データキーあるいは少なくとも該データキーの一部が郵便証印の生成のための料金納付キーの構成要素を形成することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１】
料金納付キーを用いて生成され郵便物に添付される郵便証印に含まれる暗号情報を解読して該郵便証印の信頼性の証明に用いる、郵便証印の信頼性の証明方法であって、
データキー（ＫＤ）が生成され中央支払保証システムから局所支払保証システムへと伝達されることを特徴とする方法。
【請求項２】
前記局所支払保証システムが前記データキーを受け入れ、受け入れの結果を前記中央支払保証システム（ＺｉｎＳセントラルシステム）に伝達することを特徴とする、請求項１に記載の方法。
【請求項３】
前記の受け入れの結果をデータレコードとして伝達することを特徴とする、請求項２に記載の方法。
【請求項４】
前記データレコードがキーを含むことを特徴とする、請求項３に記載の方法。
【請求項５】
前記中央支払保証システム（ＺｉｎＳセントラルシステム）が前記の受け入れの結果を確認し、これを値転送センター（郵便料金ポイント）に伝達することを特徴とする、請求項２から４のうち１つ以上に記載の方法。
【請求項６】
前記結果を前記キーの解読によって確認することを特徴とする、請求項５に記載の方法。
【請求項７】
事実上全ての前記局所支払保証システム（ＺｉｎＳローカル）への前記データキーの受け入れが成功してから、該データキーを前記値転送センター（郵便料金ポイント）において放出し、続いて新たな郵便料金額の生成に用いることを特徴とする、請求項１から６のうち１つ以上に記載の方法。
【請求項８】
前記データキーが対称キーであることを特徴とする、請求項１から７のうち１つ以上に記載の方法。
【請求項９】
新たなデータキーが前記値転送センター（郵便料金ポイント）から前記中央支払保証システムへと伝達されることを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１０】
前記値転送センターにおいて前記データキーを移送キー（ＫＴ）によって暗号化することを特徴とする、請求項９に記載の方法。
【請求項１１】
前記移送キーをマスター移送キー（ＫＴＭ）によって暗号化することを特徴とする、請求項１０に記載の方法。
【請求項１２】
前記データキーを前記値転送センターの領域内で生成することを特徴とする、請求項９に記載の方法。
【請求項１３】
前記データキーがキー識別情報を有することを特徴とする、請求項９に記載の方法。
【請求項１４】
前記キー識別情報が暗号化された形式で伝達されることを特徴とする、請求項１３に記載の方法。
【請求項１５】
前記データキーが生成カウンターを有し、さらに／あるいは該生成カウンターとともに伝達されることを特徴とする、請求項９から１４のうち１つ以上に記載の方法。
【請求項１６】
前記データキーを暗号要素、特に暗号カードへと伝達し、該暗号要素がデータキーを受信したらすぐに、伝達されたデータキーと同一の生成カウンター値を有するデータキー全てを消去することを特徴とする、請求項９に記載の方法。
【請求項１７】
前記データキーが先行するデータキーのための終了日付を有し、さらに／あるいは該終了日付とともに伝達されることを特徴とする、請求項９から１６のうち１つ以上に記載の方法。
【請求項１８】
前記料金納付キーを暗号要素に伝達し、該暗号要素が他のデータキーが終了日付を有するかどうか、および先行するデータキーのために保存されている該終了日付が前記支払保証システムに保存されている日付より古いかどうかを確認することを特徴とする、請求項１７に記載の方法。
【請求項１９】
前記データキーあるいは少なくとも該データキーの一部が郵便証印の生成のための料金納付キーの構成要素を形成することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【特許請求の範囲】
【請求項１】
料金納付キーを用いて生成され郵便物に添付される郵便証印に含まれる暗号情報を解読して該郵便証印の信頼性の証明に用いる、郵便証印の信頼性の証明方法であって、
データキー（ＫＤ）が生成され中央支払保証システム（ＺｉｎＳセントラル）から局所支払保証システム（ＺｉｎＳローカル）へと伝達され、後者に受け入れられ、受け入れの結果を該中央支払保証システム（ＺｉｎＳセントラル）に伝達するとともに、事実上全ての前記局所支払保証システム（ＺｉｎＳローカル）への該データキー（ＫＤ）の受け入れが成功してから、該データキー（ＫＤ）を新たな郵便料金額の生成のために放出することを特徴とする方法。
【請求項２】
前記データキーが先行するデータキーのための終了日付を有し、さらに／あるいは該終了日付とともに伝達されることを特徴とする、請求項１に記載の方法。
【請求項３】
前記料金納付キーを暗号要素に伝達し、該暗号要素が他のデータキーが終了日付を有するかどうか、および先行するデータキーのために保存されている該終了日付が前記支払保証システムに保存されている日付より古いかどうかを確認することを特徴とする、請求項２に記載の方法。
【請求項４】
前記データキーが生成カウンターを有し、さらに／あるいは該生成カウンターとともに伝達されることを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項５】
前記データキーを暗号要素、特に暗号カードへと伝達し、該暗号要素がデータキーを受信したらすぐに、伝達されたデータキーと同一の生成カウンター値を有するデータキー全てを消去することを特徴とする、請求項４に記載の方法。
【請求項６】
前記の受け入れの結果をデータレコードとして伝達することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項７】
前記データレコードがキーを含むことを特徴とする、請求項６に記載の方法。
【請求項８】
前記の受け入れの結果を値転送センター（郵便料金ポイント）に伝達することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項９】
前記結果を前記キーの解読によって確認することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１０】
事実上全ての前記局所支払保証システム（ＺｉｎＳローカル）への前記データキーの受け入れが成功してから、該データキーを前記値転送センター（郵便料金ポイント）において放出することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１１】
前記データキーが対称キーであることを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１２】
新たなデータキーが前記値転送センター（郵便料金ポイント）から前記中央支払保証システムへと伝達されることを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１３】
前記値転送センターにおいて前記データキーを移送キー（ＫＴ）によって暗号化することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１４】
前記移送キーをマスター移送キー（ＫＴＭ）によって暗号化することを特徴とする、請求項９に記載の方法。
【請求項１５】
前記データキーを前記値転送センターの領域内で生成することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１６】
前記データキーがキー識別情報を有することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【請求項１７】
前記キー識別情報が暗号化された形式で伝達されることを特徴とする、請求項１６に記載の方法。
【請求項１８】
前記データキーあるいは少なくとも該データキーの一部が郵便証印の生成のための料金納付キーの構成要素を形成することを特徴とする、前記の請求項のうち１つ以上に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２００６−５２７５１２（Ｐ２００６−５２７５１２Ａ）
【公表日】平成１８年１１月３０日（２００６．１１．３０）
【国際特許分類】
【出願番号】特願２００６−５０１４６６（Ｐ２００６−５０１４６６）
【出願日】平成１６年１月２１日（２００４．１．２１）
【国際出願番号】ＰＣＴ／ＤＥ２００４／００００８３
【国際公開番号】ＷＯ２００４／０７２９１１
【国際公開日】平成１６年８月２６日（２００４．８．２６）
【出願人】（５０３２７６４７０）ドイチェ ポスト アーゲー (50)
【Ｆターム（参考）】
【公表日】平成１８年１１月３０日（２００６．１１．３０）
【国際特許分類】
【出願日】平成１６年１月２１日（２００４．１．２１）
【国際出願番号】ＰＣＴ／ＤＥ２００４／００００８３
【国際公開番号】ＷＯ２００４／０７２９１１
【国際公開日】平成１６年８月２６日（２００４．８．２６）
【出願人】（５０３２７６４７０）ドイチェ ポスト アーゲー (50)
【Ｆターム（参考）】
[ Back to top ]