JP2005525731A - 物理アクセス制御 - Google Patents

Abstract

標準的な証明書フォーマットで動作するとともに、証明書Ｃの発行日から始まる任意の時間間隔（例えば、毎日、毎時、または毎分）ごとに各証明書Ｃの有効性状態を証明することを認証局（ＣＡ）に可能にさせるデジタル証明書有効性検証プロセス介した、物理アクセスを制御するシステムおよび方法が開示されている。Ｃの時間粒度は、全ての証明書に対して同じでなければ、証明書自体内で指定できる。例えば、全ての証明書の時間粒度を１日にして、各証明書が発行の３６５日後に失効するようにすることができる。ＣＡにより与えられるある初期入力が与えられると、デジタル証明書に含まれている指定されたバイトサイズの値を計算することと、秘密に保持されていて、有効性検証プロセスにおいて使用されるその他の値を計算することとのために、一方向ハッシュ関数が利用される。

Description

関連する出願に対する相互参照：
この出願は、2002年4月8日に出願された「スケーラブルな証明書検証および簡略化したＰＫＩ管理(SCALABLE CERTIFICATE VALIDATION AND SIMPLIFIED PKI MANAGEMENT)」という名称の米国仮出願第60/370,867号、2002年4月16日に出願された「クロック無し装置検証(CLOCK-LESS DEVICE VALIDATION)」という名称の米国仮出願第60/372,951号、2002年4月17日に出願された「ハッシュ・シーケンスを妨げる技術(TECHNIQUES FOR TRAVERSING HASH SEQUENCES)」という名称の米国仮出願第60/373,218号、2002年4月23日に出願された「物理アクセス制御(PHYSICAL ACCESS CONTROL)」という名称の米国仮出願第60/374,861号、2002年10月23日に出願された「セキュアな物理アクセス(SECURE PHYSICAL ACCESS)」という名称の米国仮出願第60/420,795号、2002年10月25日に出願された「ＯＣＳＰを介したリアルタイム信用証明(REAL TIME CREDENTIALS OVER OCSP)」という名称の米国仮出願第60/421,197号、2002年10月28日に出願された「リアルタイム信用証明(REAL TIME CREDENTIALS)」という発明の名称を持つ米国仮出願第60/421,756号、2002年10月30日に出願された「モバイル・コンピューティング資源の保護(PROTECTING MOBILE COMPUTING RESOURCES)」という名称の米国仮出願第60/422,416号、2002年11月19日に出願された「ケルベロス(kerberos)状の設定における秘密鍵セキュア物理アクセスまたはリアルタイム信用証明（ＲＴＣ）(PRIVATE KEY SECURE PHYSICAL ACCESS OR REAL TIME CREDENTIALS (RTCs) IN KERBEROS-LIKE SETTINGS)」という名称の米国仮出願第60/427,504号、2003年1月29日に出願された「リアルタイム検証による三要素認証(THREE-FACTOR AUTHENTICATION WITH REAL TIME VALIDATION)」という名称の米国仮出願第60/443,407号、及び2003年2月10日に出願された「下位カードによるＲＴＣ物理アクセス(RTC PHYSICAL ACCESS WITH LOWER-END CARDS)」という名称の米国仮出願第60/446,169号、を基にしている。これらの教示の全ては参照することによってここに包含される。

この出願は、2002年3月20日に出願された「スケーラブルな証明書検証および簡略化したＰＫＩ管理(SCALABLE CERTIFICATE VALIDATION AND SIMPLIFIED PKI MANAGEMENT)」という名称の米国特許出願第10/103,541号（係属中）、この出願の教示は参照することによってここに包含される、の一部継続出願である。米国特許出願第10/103,541号自体は、2001年7月25日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第09/915,180号（係属中）の一部継続出願である。米国特許出願第10/103,541号は、2000年1月14日に出願された米国特許出願第09/483,125号（係属中）の継続出願である。米国特許出願第09/483,125号は、1999年7月19日に出願された米国特許出願第09／356,745号（係属中）の継続出願である。米国特許出願第09/356,745号は、1997年3月24日に出願された米国特許出願第08/823,354号（現在は米国特許第5,960,083号）の継続出願である。米国特許出願第08/823,354号は、1995年11月16日に出願された米国特許出願第08/559,533号（現在は米国特許第5,666,416号）の継続出願である。米国特許出願第08/559,533号は、1995年10月24日に出願された米国仮出願第60/006,638号を基にしている。

米国特許出願第10/103,541号は、1997年12月18日に出願された米国特許出願第08/992,897号の一部継続出願でもある。米国特許出願第08/992,897号は、1996年12月18日に出願された米国仮出願第60/033,415号を基にしている。米国特許出願第08/992,897号は、1996年9月19日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/715,712号（放棄）の一部継続出願である。米国特許出願第08/715,712号は、1995年10月2日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/004,796号を基にしている。

米国特許出願第08/992,897号は、1996年10月11日に出願された「ツリー（木）を基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/729,619号（現在は米国特許第6,097,811号）の一部継続出願でもある。米国特許出願第08/729,619号は、1995年11月2日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/006,143号を基にしている。

米国特許出願第08/992,897号は、1997年2月24日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/804,808号（放棄）の一部継続出願でもある。米国特許出願第08/804,808号は、1996年11月1日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/741,601号（放棄）の継続出願である。米国特許出願第08/741,601号は、1995年11月2日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/006,143号を基にしている。

米国特許出願第08/992,897号は、1997年6月11日に出願された「証人を基にした証明書取消しシステム(WITNESS-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/872,900号（放棄）の一部継続出願でもある。米国特許出願第08/872,900号は、1996年11月5日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/746,007号（現在は米国特許第5,793,868号）の継続出願である。米国特許出願第08/746,007号は、1996年8月29日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/025,128号を基にしている。

米国特許出願第08/992,897号は、1997年2月3日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/035,119号を基にもしており、かつ、1997年8月5日に出願された「証人を基にした証明書取消しシステム(WITNESS-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/906,464号（放棄）の一部継続出願でもある。米国特許出願第08/906,464号は、1996年12月9日に出願された「証人を基にした証明書取消しシステム(WITNESS-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/763,536号（現在は米国特許第5,717,758号）の一部継続出願である。米国特許出願第08/763,536号は、1996年9月10日に出願された「証人を基にした証明書取消しシステム(WITNESS-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/024,786号を基にしており、かつ、1996年4月23日に出願されたという名称の米国特許出願第08/636,854号（現在は米国特許第5,604,804号）を基にしており、さらに、1996年8月29日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/025,128号を基にもしている。

米国特許出願第08/992,897号は、1996年11月26日に出願された「セグメント化された証明書取消しリスト(SEGMENTED CERTIFICATE REVOCATION LISTS)」という名称の米国特許出願第08/756,720号（放棄）の一部継続出願でもある。米国特許出願第08/756,720号は、1996年8月29日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/025,128号を基にしており、かつ、1996年9月19日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/715,712号（放棄）を基にしてもおり、さらに、1995年11月16日に出願された米国特許出願第08/559,533号（現在は米国特許第5,666,416号）を基にしている。

米国特許出願第08/992,897号は、1996年11月19日に出願された「証明書発行リスト(CERTIFICATE ISSUE LIST)」という名称の米国特許出願第08/752,223号（現在は米国特許第5,717,757号）の一部継続出願である。米国特許出願第08/752,223号は、1996年8月29日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/025,128号を基にしており、かつ、1997年2月24日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/804,869号（放棄）を基にもしている。米国特許出願第08/804,869号は、1996年11月1日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/741,601号を基にしている。米国特許出願第08/741,601号は、1995年11月1日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/006,143号を基にしている。

米国特許出願第08/992,897号は、1997年3月24日に出願された「証明書取消しリスト(CERTIFICATE REVOCATION LISTS)」という名称の米国特許出願第08/823,354号（現在は米国特許第5,960,083号）の一部継続出願でもある。米国特許出願第08/823,354号は、1995年11月16日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/559,533号（現在は米国特許第5,666,416号）の継続出願である。米国特許出願第08/559,533号は、1995年10月24日に出願された「強化された証明書取消しシステム(ENHANCED CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/006,038号を基にしている。

米国特許出願第10/103,541号は、2001年3月20日に出願された米国仮出願第60/277,244号と、2001年6月25日に出願された米国仮出願第60/300,621号と、2001年12月27日に出願された米国仮出願第60/344,245号とをも基にしている。上記の全ては参照することによりここに包含される。

本出願は、2001年6月25日に出願された、「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第09/915,180号（係属中）、米国特許出願第09/915,180号の教示は参照することによってここに包含される、の一部継続出願でもある。米国特許出願第09/915,180号自体は、2000年1月14日に出願された米国特許出願第09/483,125（係属中）号の継続出願である。米国特許出願第09/483,125号は、1999年7月19日に出願された米国特許出願第09/356,745号（放棄）の継続出願である。米国特許出願第09/356,745号は、1997年3月24日に出願された米国特許出願第08/823,354号（現在は米国特許第5,960,083号）の継続出願である。米国特許出願第08/823,354号は、1995年11月16日に出願された米国特許出願第08/559,533号（現在は米国特許第5,666,416号）の継続出願であり、米国特許出願第08/559,533号は、1995年10月24日に出願された米国特許出願第60/006,038号を基にしている。

本出願は、2003年3月21日に出願された「効率的な証明書取消し(EFFICIENT CERTIFICATE REVOCATION)」という名称の米国特許出願第10/395,017号（係属中）、米国特許出願第10/395,017号の教示は参照することによってここに包含される、の一部継続出願でもある。米国特許出願第10/395,017号自体は、2002年9月16日に出願された米国特許出願第10/244,695号（係属中）の継続出願である。米国特許出願第10/244,695号は、1997年12月18日に出願された米国特許出願第08/992,897号（現在は米国特許第6,487,658号）の継続出願である。米国特許出願第08/992,897号は、1996年12月18日に出願された米国仮出願第60/033,415号を基にしており、かつ、1996年9月19日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/715,712号（放棄）の一部継続出願である。米国特許出願第08/715,712号は、1995年10月2日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第60/004,796号を基にしており、かつ、1996年10月10日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/729,619号（現在は米国特許第6,097,811号）の一部継続出願でもある。米国特許出願第08/729,619号は、1995年11月2日に出願された「ツリーを基にした証明書取消しシステム(Tree-Based CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/006,143号を基にしており、かつ、1997年2月24日に出願された「ツリーを基にした証明書取消しシステム(Tree-Based CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/804,868号（放棄）の一部継続出願でもある。米国特許出願第08/804,868号は、1996年11月1日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/741,601号（放棄）の継続出願である。米国特許出願第08/741,601号は、1995年11月2日に出願された「ツリーを基にした証明書取消しシステム(TREE‐BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/006,143号を基にしており、かつ、1997年6月11日に出願された「証人を基にした証明書取消しシステム(WITNESS-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/872,900号（放棄）の一部継続出願でもある。

米国特許出願第08/872,900号は、1996年11月5日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/746,007号（現在は米国特許第5,793,868号）の継続出願である。米国特許出願第08/746,007号は、1996年8月29日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第60/025,128号を基にしており、かつ、1997年2月3日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第60/035,119号を基にもしており、かつ、1997年8月5日に出願された「証人を基にした証明書取消しシステム(WITNESS-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/906,464号（放棄）の一部継続出願でもある。米国特許出願第08/906,464号は、1996年12月9日に出願された「証人を基にした証明書取消しシステム(WITNESS-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/763,536（現在は米国特許第5,717,758号）の継続出願である。米国特許出願第08/763,536号は、1996年9月10日に出願された「証人を基にした証明書取消しシステム(WITNESS-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第60/024,786号を基にしており、かつ、1997年4月23日に出願された米国特許出願第08/636,854号（現在は米国特許第5,604,804号）と、1996年8月29日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/025,128号とを基にもしており、かつ、米国特許出願第08/992,897号は、1996年11月26日に出願された「セグメント化された証明書取消しリスト(SEGMENTED CERTIFICATE REVOCATION LISTS)」という名称の米国特許出願第08/756,720号（放棄）の一部継続出願でもある。米国特許出願第08/756,720号は、1996年8月29日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/025,128号を基にしており、かつ、1996年9月19日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/715,712号（放棄）を基にしてもおり、さらに、1995年11月16日に出願された米国特許出願第08/559,533号（現在は米国特許第5,666,416号）を基にしており、かつ、1996年11月19日に出願された「証明書発行リスト(CERTIFICATE ISSUE LIST)」という名称の米国特許出願第08/752,223号（現在は米国特許第5,717,757号）の一部継続出願でもある。米国特許出願第08/752,223号は、1996年8月29日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/025,128号を基にし、かつ、1997年2月24日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/804,469号（放棄）の一部継続出願である。米国特許出願第08/804,469号は、1996年11月1日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/741,601号（放棄）を基にしている。米国特許出願第08/741,601号は、1995年11月2日に出願された「ツリーを基にした証明書取消しシステム(TREE-BASED CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/006,143号を基にしており、かつ、1997年3月24日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/823,354号（現在は米国特許第5,960,083号）の一部継続出願でもある。米国特許出願第08/823,354号は、1995年11月16日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国特許出願第08/559,533号（現在は米国特許第5,666,416号）の継続出願である。米国特許出願第08/559,533号は、1995年10月24日に出願された「証明書取消しシステム(CERTIFICATE REVOCATION SYSTEM)」という名称の米国仮出願第60/006,038号を基にしている。上記の全ての教示は参照することによってここに包含される。

技術分野：
本発明は、デジタル証明書の分野に関し、特に、物理アクセスを制御するためのデジタル証明書検証の分野に関するものである。

要するに、デジタル証明書（Ｃ）は、いくつかの量、すなわち、その証明書に一意の一連番号ＳＮと、ユーザの公開鍵ＰＫと、ユーザの識別子Ｕと、発行日Ｄ₁と、満了日Ｄ₂と、付加フィールドと、を一緒に安全に結び付ける認証局（ＣＡ；Certifying Authority）のデジタル署名よりなる。記号で表わすと、Ｃ＝ＳＩＧ_CA(ＳＮ，ＰＫ，Ｕ，Ｄ₁，Ｄ₂，...)である。

デジタル証明書は、インターネットおよびその他のアクセス認証の最良の形を提供することが広く認識されている。しかし、それらは管理することが困難でもある。証明書は１年（すなわち、Ｄ₂−Ｄ₂＝１年）後に失効することがあるが、例えば、証明書の保持者が勤務先を辞めたり、勤務先内部で異なる職務に就いたりしたことによって、期限切れの前に取消されることがある。したがって、所与のデジタル証明書により使用可能にされる各トランザクションは、その証明書の現在の有効性の適切な証明を必要とし、かつその証明は、しばしば、将来のクレームへの対策として記録しておく必要がある。

不幸なことに、発行された証明書の有効性を立証する従来の技術は、スケーラブルではない。近い将来に予想されるデジタル証明書の量では、現在の有効性証明は、セキュアなやり方では行えなくなるか、（特に無線装置において）伝送のために時間がかかりすぎしたがってコストがかかりすぎる。証明書の検証は、厳しい問題として、一般的に認識されている。効果的に解決されなければ、それはＰＫＩの成長および有用性を厳しく制約するであろう。

今日、証明書の有効性を立証するために、証明書取消しリスト（ＣＲＬ；Certificate Revocation List）およびオンライン証明書状態プロトコル（ＯＣＳＰ；Online Certificate Status Protocol）の二通りの主なやり方がある。

ＣＲＬ：
ＣＲＬは定期的に発行される。ＣＲＬは、本質的に、取り消された証明書の一連番号の全てを含んでいる、ＣＡが署名したリストで構成されている。電子トランザクションで提示されるデジタル証明書は、その後で、最新のＣＲＬと比較される。与えられた証明書が期限切れではないが、リストに載せられているとすると、その証明書は有効ではなくその証明書の保持者はそのトランザクションの実行をもはや許可されていないことを、ＣＲＬからあらゆる人が知る。その他の場合は、証明書がＣＲＬに現れないとすると、その証明書は有効である（二重否定）と推定される。

ＣＲＬは、管理できないほど長くなるかもしれないとのおそれ（最新のＣＲＬ区分化技術によってかろうじて弱められてきたに過ぎないおそれ）から、多くの賛同を受けているわけではない。何年か前に、米国標準技術局(National Institute of Standard and Technology)は、ＭＩＴＲＥ社(MITRE Corporation)に対して、連邦政府のための公開鍵基盤（ＰＫＩ；Public Key Infrastructure）の構成および費用について研究することを依頼した（Public Key Infrastructure, Final Report; MITRE Corporation; National Institute of Standard and Technology, 1994（公開鍵基盤、最終報告書；ＭＩＴＲＥ社；米国標準技術局、１９９４年）を参照）。この研究は、ＣＲＬが連邦ＰＫＩのコストリスト中で非常に大きな項目（エントリ）を構成する、と結論している。

ＯＣＳＰ：
ＯＣＳＰにおいては、ＣＡが、現時点におけるＣの有効性状態の、ＣＡ自身のデジタル署名を戻すことにより、証明書Ｃについての質問（クエリ）に答える。下記の領域ではＯＣＳＰは問題を含んでいる。

帯域幅： ＯＣＳＰにより発生された各有効性証明は、ささいではない長さを持つ。ＲＳＡまたはその他の因数分解を基にした署名方式が用いられたとすると、そのような証明は、実際には、ＣＡの署名に対して最少２０４８ビットを要する。

計算： デジタル署名は、計算上は、複素演算(complex operation)である。ある大きな応用では、ピークトラフィックにおいて、ＯＣＳＰは短時間で何百万もの署名を計算することを要することがある。それは、実行するには、計算コストが非常に高い。

通信（集中化された場合）： 集中化された形態で、単一の検証サーバがＯＣＳＰを実装したと仮定する。すると、全ての証明書の有効性についてのクエリが、最終的に、そのサーバに仕向けられなければならず、そうするとサーバはかなりの混雑と遅延をひき起こす大きな「ネットワークの隘路（ボトルネック）」となろう。。ものすごい数の正直なユーザがサーバに対して突然質問したとすると、混乱をもたらす「サービスの拒絶(denial of service)」がおそらく続いて起こるであろう。

セキュリティ（分散化している場合）： 一般に、単一のサーバの負荷を、世界中に戦略的に配置されているいくつかの（例えば、１００の）サーバに分散すると、ネットワークの混雑が緩和される。しかし、ＯＣＳＰの場合には、負荷分散でそれが解決する問題よりも悪い問題がもたらされる。それが受ける証明書クエリに対するそれの応答に署名するために、１００のサーバのおのおのはそれ自身の秘密署名鍵を持たなければならない。したがって、１００のサーバのいずれかを妥協することはシステム全体を妥協することである。セキュアな保管庫(secure vault)はそのような分散サーバを保護できるが、それには巨額の費用を要する。

発明の概要：
標準的な証明書フォーマットで動作するとともに、証明書Ｃの発行日から始まる任意の時間間隔（例えば、毎日、毎時、または毎分）ごとに各証明書Ｃの有効性状態を証明することを認証局（ＣＡ；certifying authority）に可能にさせるデジタル証明書有効性検証プロセス介した、物理アクセスを制御するシステムおよび方法が開示されている。Ｃの時間粒度(time granularity)は、全ての証明書に対して同じでなければ、証明書自体内で指定できる。例えば、全ての証明書の時間粒度を１日にして、各証明書が発行の３６５日後に失効するようにすることができる。ＣＡにより与えられるある初期入力が与えられると、デジタル証明書に含まれている指定されたバイトサイズの値を計算することと、秘密に保持されていて、有効性検証プロセスにおいて使用されるその他の値を計算することとのために、一方向ハッシュ関数が利用される。

物理アクセスの制御には、リアルタイム信用証明体(credentials)を調べることが含まれる。ここに、リアルタイム信用証明体は、固定されている第１の部分と、定期的に変更される第２の部分とを含む。第２の部分は、リアルタイム信用証明体が現在通用のものであるという証明を与え、第２の部分に対して操作を行いそれの結果を第１の部分と比較することによって、リアルタイム信用証明体が有効であると検証された場合にのみ物理アクセスを行えるようにする。第１の部分は、権限機関(authority)によってデジタル署名されることができる。権限機関が第２の部分を提供してもいいし、または、第２の部分は権限機関以外のエンティテイ(entity)により提供されてもよい。リアルタイム信用証明体は、スマートカードにより提供されてもよい。ユーザは、第１の場所でリアルタイム信用証明体の第２の部分を得ることができる。ユーザは、第１の場所とは離れ異なっている第２の場所にアクセスすることを許されることがある。リアルタイム信用証明体の第１の部分の少なくとも一部が、リアルタイム信用証明体の第２の部分の一部に対して複数の回数にわたって適用される一方向ハッシュを表すことができる。複数の回数は、リアルタイム信用証明体の第１の部分が発行されてから経過した時間の長さに相当することがある。物理アクセスの制御は、ドアを通じるアクセスを制御することを含んでもよい。

添付図面のいくつかの図を参照して本発明を説明する。

セキュアな物理アクセス：
保護されている区域を権限を与えられた人のみがアクセスするように保証することは、極めて重要である（例えば、空港、軍事施設、オフィスビル等）。保護されている区域は、物理的なドア（特に、人がそれを通って入ることができるドア、または容器、金庫あるいは車両の扉）や壁によって区切ることができ、またはその他のやり方で仮想的に区切ることができる。例えば、保護されている区域は、その中に入ることによって検出器が侵入を知らせる（およびおそらくは、権限が与えられていなければ信号を送るか音を発する）ような区域よりなる。空港では、たいてい、出口レーンを通ってゲート区域に入ると、ドアや壁が破られなかった場合であっても、そのような信号の発生がひき起こされるだろう。なお、この出願を通じて、ドアというのは、従来の鍵やより最新の種類の鍵で実現できる他の種類のアクセスアクセス管理装置の全てを含むものであると解すべきである。特に、エンジンを始動するために用いられるキー機構（したがって、我々の発明は、現在、権限を与えられているユーザのみが航空機やトラックを始動したり、またはその他の有価物にアクセスしたりできるようにする新規なやり方になる）。

我々の文脈の一般性を、その後に具体的に、ただし意図した一般性を失うことなしに、説明するが、「ドア」のことをアクセスを管理する手段、または周囲を定める手段と呼び、「入ること(entering)」を防護しようと望む区域をアクセスする手段と呼ぶことにする。

スマートドアは、そのようなアクセス管理を提供する。最も簡単なレベルでは、スマートドアには、キーパッドを設けることができる。そのキーパッドによってユーザは、彼／彼女のＰＩＮまたはパスワードを入力する。キーパッドには、メモリまたは基本プロセッサが取り付けられ、そのメモリまたは基本プロセッサには。有効なＰＩＮ／パスワードのリストが保存されているので、いま入ろうとしている人がそのリストに属しているかどうかを調べることができる。もし属しているならば、ドアが開くが、そうでなければロックされたままである。そのような基本的なアクセス制御機構は、最小限の安全性を提供する。特に、解雇された被用者はもはやそのドアを通る権限を受けない。しかし、彼が彼自身のＰＩＮを依然として記憶しているならば、彼はそのような基本的なスマートドアを開くのに面倒はない。したがって、解雇された被用者のＰＩＮを「プログラムから取り除く」必要がある。しかし、そのような作業は非常に面倒でかつ費用を要することがある。空港施設には何百というドアがあることがあり、被用者が退職または解雇されるたびに特殊な作業員チームを派遣して全てのドアのプログラムを変更することは、余りにも非実用的である。より強固なセキュリティは確かに必要であるが、それには過大な費用を要することと便利さを犠牲にすることは無しである。

もちろん、従来のキーまたは単純なキーパッドに（全面的に）依存するよりも、より近代的なスマートドアを、スマートカードおよびマグストリップ(mag-strip)カード、すなわち非接触デバイスなどのカード（の代わりに、または、とともに）使用することができる。しかしこの強化されたツールセットは、それ自体がアクセス管理システムのセキュリティと利便性と低い費用とを保障するものではない。それらは、そのようなツールが全体的なセキュリティアーキテクチャにおいてどのように使用されるかに決定的に依存する。

理想的には、スマートドアは、入る人を識別し、その人が現在入ることを権限付けられていることを調べなけばならない。２つの作業のうち、最初のものが多分一層容易である。識別は種々のやり方で行うことができる。特に、
１． ＰＩＮやパスワードを使用する。それらはドアに組合わせされているキーパッドで入力できる；
２． バイオメトリックスを使用する。それはドアに組合わされている特殊な読取器を用いてユーザが入力できる；
３． ドアに組合わされている特殊なパッドを介してユーザにより入力される通常の署名を使用する；
４． （例えば、特殊な読取器／受信器を介してＰＩＮをドアへ送る）スマートカードまたは非接触カードを使用する；
５． 例えば、スマートカード、非接触カードまたは無線装置に記録されているデジタル証明書を使用する。それはカード読取器またはその他の受信器を介して「ドアと交信」できる。

本発明者らは、デジタル証明書は本発明のシステムで使用するのに特に魅力的であると信ずる。したがって、本発明者らは、本発明のシステムに組み合わせることを考えているスマートドアとともにそれらの証明書を使用するための何等かの方法をもう少し高度にすることを望んでいる。具体的には、ただし意図された一般性を失うことなしに、アクセスを望む人が所有するデバイスのことを「カード」と呼ぶことにする。そのカードにはデジタル証明書と対応する秘密鍵を記録できる。カードの所持者から適切な指令が与えられると（例えば、カード上のキーパッドに秘密コードをキー入力することにより行われると）、そのカードは、デジタル証明書をドア機構へ送り、対応する秘密鍵を用いて、識別プロトコルを実行する（例えば、ランダムなチャレンジを解読する）。デジタル証明書、特にそれの対応する秘密鍵は。カード／デバイスのセキュアなハードウェア部分内で保護されていることが好ましい。

ある場合には、匿名ではあるが、セキュアなアクセス管理が望まれる。この場合には、識別を行う必要はないが、認証を行う必要は依然としてある。しかし、ほとんどの場合には、何等かの態様での識別が行われる。したがって、識別を行うことができるか、識別が（例えば、上記５つのやり方のうちの任意の１つにより）既に行われたと仮定できる。いずれにせよ、認証はどのように行われるか？ 某氏と係わり合っていることをドアが確実に知っているとしても、その某氏がいま入ることを現在許可されていることをドアはどのようにして確認できるのか。従来は、スマートドアは、その個人が確かにアクセスを要求したを検証するために、現在（例えば、所与の日／日付で）許可されているユーザをデータベースにおいて参照する。しかし、それは、スマートドアが遠隔のデータベースに接続されるべきことを要求する。さらに、これは通常のネットワーク接続ではなく、セキュアなネットワーク接続でなければならない。実際には、欺こうとする人間がドアに対するデータベースに対してなりすましを行うことを防止するために、暗号で保護された通信を使用しなければならないばかりか、ドアをデータベースに接続している線を敵が切断することを防止しなければならない。さもないと、ひとたび切断されると、ドアは等しく悪い選択肢、（ａ）常に開いている、または（ｂ）常に閉じている、から選択しなければならないからである。しかし、セキュアなネットワーク接続は、容易に、ドアの錠前の電気機械的な部品の費用を小さく見せる。例えば、最も高価な線部品は１０００ドルすることがあるが、セキュアなネットワーク接続の費用は４０００ドル（空港におけるように、長距離にわたって線を安全に接続するならばそれ以上）になることがある。さらに、そのような４０００ドルを支出した後でも、空港のような公共的な場所に、セキュアなネットワーク接続のようなものがあるだろうか？ 遠方のデータベースまでの無線接続をスマートドアに備えることは、いずれに対しても実行可能な選択肢ではないことに注目されたい。まず第一に、長距離無線用の送信機および受信機は高価である。第２に、ある施設では、（他の機器に与えるおそれのある妨害を避けるために）無線の帯域幅が厳しく制限されることがあり、またはそのような用途では完全に禁止される。第３に、ドアをデータベースから実効的に切り離す（それにより２つの等しく悪い判定を選択させる）ように、無線通信は電磁波で容易に妨害（ジャミング）されることがある。第４に、大西洋の真ん中にある容器にドアが設けられているとすると、陸上にあるどのようなデータベースとも無線で通信することはできる可能性はほとんどない。

したがって、本発明の１つの態様は、安価で、便利かつセキュアな非接続のドア、すなわち、いかなるデータベースまたは権限機関にも（有線であれ、無線であれ）接続されていない、安価で、便利かつセキュアなスマートドアを提供する。

デジタル署名および証明書：
好適な実施形態では、本発明はデジタル証明書に依存し、好ましくは２０バイト技術に依存する。デジタル署名（ＲＳＡなど）は、与えられたメッセージＭが所与のユーザＵから由来するものであることを証明するために用いられる。そのために、Ｕは一対の照合鍵、すなわち検証鍵ＰＫと署名鍵ＳＫを生成する。デジタル署名はＳＫを介して生成され、照合鍵ＰＫを介して検証される。ユーザＵは、（ＵのみがＵのために署名できるように、）彼自身のＳＫを秘密に保つべきである。ＰＫは、照合鍵ＳＫの「秘密を漏らさない」、すなわち、ＰＫについての知識は、ＳＫの計算においてなんら実用的な利益を敵に与えないので、デジタル署名は機能する。したがって、ユーザＵは、（誰でもＵの署名を検証できるように、）彼自身のＰＫをできるだけ公開すべきである。この理由から、ＰＫは公開鍵と呼ぶことが好ましい。メッセージＭについてのＵのデジタル署名をＳＩＧ_U(Ｍ)で示すことにする。デジタル署名は、個人鍵(private-key)署名を含むことを意図している。その場合には、署名されたものおよび検証者(verifier)は、共通の秘密鍵(secret-key)を共用する。

証明書と呼ばれる英数字列は、所与の鍵ＰＫが実際にユーザＵの公開鍵であることを保証することにより、デジタル署名を可能にする。ユーザの身元がひとたび確認されたならば、認証局（ＣＡ；Certifying Authority）が証明書を発行してユーザに与える。このようにして、証明書は、ＣＡが保持者の身元と、できるならばその他の属性とを検証したことを誰にでも示す。（例えば、ある会社がそれ自身のＣＡとして動作し、それ自身の被用者に証明書を発行するならば、証明書は、彼／彼女の使用者に結び付けられる、その証明書の保持者が権限を与えられた範囲を示すことができる。）証明書は、指定期間、公開ＣＡの場合には典型的には１年間、の経過後に失効する。要するに、デジタル証明書Ｃは、いくつかの量、すなわち証明書に一意の一連番号ＳＮとユーザの公開鍵ＰＫとユーザ名Ｕと発行日付Ｄ₁と失効日付Ｄ₂と付加データとをセキュアに結びつけるＣＡのデジタル署名からなる。記号で表わすと、Ｃ＝ＳＩＧ_CA(ＳＮ，ＰＫ，Ｕ，Ｄ₁，Ｄ₂，...)である。

証明書は、ＰＫが暗号化鍵(encryption key)である場合も包含する。この場合には、Ｕは、証明書Ｃを検証者Ｖへ送り、Ｖがランダムチャレンジ（文字列）Ｒを鍵ＰＫで暗号化し、その後で、解読したものを送り返すことをＶがＵに求めることにより、ユーザの身元をＶに対して証明することができる。ユーザがＲで応答したならば、Ｖは、Ｕと応対していることを保証される。その理由は、Ｕのみが、ＰＫに適合する解読鍵(decryption key)を知っているからである。

本発明の好適な実施形態は、アクセス管理のためにはるかに優れた解決策を提供する。特に、カードに本発明に基づくデジタル証明書が含まれているならば、はるかに安いコストで認証を行うことができる。あらゆるデジタル証明書の有効性について中央のデータベースに照会する代わりに、ドアはそのカードの現在の有効性を検証する、本発明に基づく２０バイト有効性証明を得る必要があるだけである。

例１：
ここで、Ａを、１組のスマートドアを管理する権限機関（すなわちエンティティ）とし、Ｕを、所与のドアに対するアクセスを所与の時間だけ許されているユーザとする。

各ユーザは、（前述した一般的な意味での）カードを有する。

各スマートドアには、（一般的な意味で、通信することができ、または少なくともユーザカードから情報を受け取ることできる）カード読取器が組合わされている。（むしろ仮想ではなく）実際の物理的なドアの場合には、そのカード読取器には、電気機械的な錠が結合されている。各ドアは、一意の識別子も有する（とともにそれ自身の識別子も知っている）ことが好ましい。ドアは、カード読取器と、容易には変更できないクロックと、Ａの公開鍵ＰＫＡを保持しかつＡの署名を検証できる計算装置と、を有する、
権限機関は、所与の時間間隔内にどのユーザがどのドアを通ることができるかを決定する。（例えば、意図している一般性を失うことなしに、ここで話題としている各時間間隔は日であると仮定できる。）そのために、Ａは、全ての許可（パーミッション）すなわち所与の時間（または予見できる将来の日）にどのドアを通ることを誰が許可されるか、を蓄積している、Ａ自身の私的データベースＤＢ１を使用できる。おそらく、Ａはこのデータベースを保護する。さもなければそこに蓄積されている許可を敵がその敵自身の利益のために変更できる。しかし、Ａは、公開データベースＰＤＢを、ＤＢから次のようにして計算する。ｄ日にドアＤを通る許可を得ている各ユーザＵについて、Ａは、実際にそうであることを示すデジタル署名ＳＵＤｄを計算する。例えばＡは、ＳＵＤｄ＝ＳＩＧ_A(Ｕ，Ｄ，ｄ)を計算する。Ａのみがそれらのデジタル署名を計算でき、Ａの公開鍵ＰＫＡを持つ全てのものはそれらを検証できることに注目されたい。それらの署名は、Ａの秘密鍵ＳＫＡを知らない何者かによって偽造可能ではなく、かついかなるやり方で（例えば、Ｕの許可を無権限のユーザＵ'に対する許可に変換することにより）署名を変更してもそれらは無効にされる。したがって、Ａは、大いに気にかけることなく、それらの署名を適時に（例えば、１日の初めに）計算して蓄積場所(repository)ＰＲへ送ることができる。蓄積場所というのは、ユーザがアクセスできる場所のことである。例えば、大規模な施設の従業員入口（空港の従業員入口など）に設置されているサーバである。Ａの署名は偽造できないので、ＡとＰＲとの間の接続はセキュアである必要はない。Ａはそれの署名を妥当な時間内にＰＲへ送り続けるだけで十分である。

被用者Ｕが、（例えば、ＰＲが設けられている入口の点を通って）ｄ日に施設に仕事で到着すると、彼は彼のカードをＰＲに接続できる（例えば、彼は、ＰＲに接続されているかまたはＰＲと遠隔通信するカード読取器／書込器に、彼のカードを挿入する）。そうすることにより彼は、彼のカード上に。ＳＩＧＵＤすなわちその日に彼がドアを通ることを許可されていることを示すデジタル署名をピックアップする。これは、何百ものドアではなくて入口の点がＡに接続されることを要する。この接続はセキュアである必要はない。実際には、Ｄは単一のドアを示す必要はない。例えば、それは１組のドア（例えば荷物取扱いドア）を示すことができ、Ａの署名は、ＵがＤにより示されている各ドアを通ることができることを示す。あるいは、複数のドアＤ１，...，Ｄｎを１つずつ示すことができ、Ｕがその日にそれらのドアの各１つを通ることができるという事実をＡの複数の署名により示すことができる。例えば、ＳＩＧＵＤ１ｄ，...，ＳＩＧＵＤｎｄである。その場合には、そのような署名の全てがＵのカードへ転送される。

ここで、ｄ日のうちにＵが施設の周囲を歩いて彼が許可されているドアＤに達したと仮定する。したがって、彼のカードは、今や、ＳＩＧＵＤｄを保存している。するとＵは、彼のカードＣをドアＤの所のカード読取器に挿入できる。そうすると、ドアに組合わされているプロセッサが、Ａの公開鍵を用いて、ＳＩＧＵＤｄが確かに有効であることを検証する。その後で、現在の日付けが確かにｄであることをそれ自身のクロックを用いて検証する。両方の項目が真であるならば、ドアＤは開く。ドアは、カード保持者が確かにそうであることを、種々のやり方で識別を行うことにより調べることができることに注目されたい。特に、Ｕは、ドアに組合わされているキーパッドに彼のＰＩＮを入力することも求められるかもしれない。（前とは異なって、解雇された被用者が自身のＰＩＮを記憶していたとしても、彼はドアＤを通ることはできないことに注目されたい。実際に、この例では、ドアはＰＩＮと現在の日のための正しい署名の両方を必要とする。しかし、Ｕが解雇された後では、Ａは、以後のどのような日ｄに対しても署名ＳＩＧＵＤｄを発行しないので、Ｕは、そのような署名をドアに提供できない。また彼は、Ａのそのような署名を偽造できない。したがって、彼は解雇された後ではどの日にもドアＤが開くことを「確信」できない。）あるいは、ＵがＣの裏面にあるキーパッド上に正しいＰＩＮを入力した場合にのみ、カードはＳＩＧＵＤｄをＤのカード読取器に転送でき、カードが確かにＵのカードであることを証明した後でのみ、蓄積場所ＰＲはＳＩＧＵＤｄをカードＣにダウンロードできる。あるいは、Ｕは、Ｕに属している、カードＣのための識別子を表してもよく、カード読取器に挿入されると、そのカードは、例えば暗号プロトコルにより、確かにそれがカードＣであることを確実に証明する。あるいは、および好ましくは、ＵのカードがＵについての証明書を保持し、適正なＰＩＮが入力された後で、カードはドアのランダムなチャレンジを解読することによりＵが本人であることを証明する。この場合には、ＳＩＧＵＤｄが、Ｕの証明書がその持ち主に対するその許可を保持していることを示すことにより、ＵがドアＤを通る許可を持っていることを示すことが好ましい。例えば、ＳＩＧＵＤｄ＝ＳＩＧｕＤｄであり、ここにｕは、Ｕの証明書の一連番号（および発行者）などの、Ｕの証明書に対する識別子である。

それらのやり方の全てにおいて、ドアはＡから「非接続である」ことを理解すべきである。ドアは、内部計算とＡの公開鍵の使用とそれ自身の内部クロックを利用することとによって、（おそらくＵを識別し、）入ることの許可をＵが保持しているかをチェックする。したがって、このシステムは非常にセキュアであるばかりでなく、非常に経済的でもある。

この有効性または権限の証明は、いくつかの異なるやり方で提供できる。下記は、これをどのようにして行うことができるかのまさにその例である。

例２：
カードの所有者は、有効性証明を適切な時刻に「ピックアップ」できる。例えば、作業環境では、各人は、作業を報告する際に現在の有効性証明をピックアップできる。多くの作業場所（特に、空港などのセキュリティが重要である場所）では、被用者は、作業を報告する場合に、「サインイン（到着の署名）(sign in)」をする。この「サインイン」は、２０バイトの有効性すなわちＳＩＧＵＤｄを得ることと、それをカードに保存することと、値を得ることと、それをカードに保存することとを含む。カードは、有線接続または無線接続によって、その値を得ることができる。

例３：
カードは、例えばぺージャーネットワークなどの無線ネットワークを介して、有効性証明を得ることができる。適切な時刻に、カードがアクセスを許可されていれば、２０バイト値がそれへ送られる。帯域幅の要求は最小であり、許可（認証）値は、ぺージャーネットワークにより伝送される典型的なメッセージより短いことに注目されたい。適切な時刻に、カードがアクセスを許可されていれば、ＳＩＧＵＤｄはそれへ送られる。

例４：
ドアは、同様に、遭遇することが事前に予測されるあらゆるカードに対して、有効性証明を有線ネットワークまたは無線ネットワークを介して前もって得てもよい。

例５：
ドアは、カードがドアとのやりとりを開始すると、カードについての有効性証明を要求に応じて得ることができる。

上記方法のいずれも、ドアと中央サーバとの間のいかなる種類のセキュアな接続も要しないことに注目されたい。その理由は、有効性証明が自己認証(self-authenticating)するからであって、ドアが有効性証明を信頼できない出所（ソース）から受け取ることと、セキュアでない接続を通じて受けることとの少なくとも一方が行われたとしても、有効性証明が正確であることを依然として確認できる。それらの方法が、ドアのために全く接続を要しないという事実によって、大きい及び／または離れた区域と、多数のドアが設けられている区域と、航空機やトラックのドアなどのモバイル区域とにおける、アクセス管理のためのはるかに良い手段が得られる。

またこの出願の全体を通して、ドアおよ防護される区域は、従来の鍵またはモダンな形式の鍵を用いて防護できる、他のあらゆる種類のアクセスポイントを含むものと解釈すべきである。特に、（現在許可されている被用者のみが航空機、トラックまたはその他のエンジンを始動できるように、）エンジンを始動するために使用されるキー機構。

当業者は、２０バイト有効性証明が特殊な限定された種類のデジタル署名技術であって、それにより小型かつ効率的であるなどの独特の利益が得られるが、おそらく有効性検証技術なしに、より一般的なデジタル署名方式をもって本発明を実施することによって、その他の多くの利益が得られることを、理解できる。本発明の好適な実施形態の構成要素は、（１）検証に合格したときにドアを開く手段に結び付けられ、デジタル署名を検証できるドア機構、（２）所与の時間期間の間、ドアを通って入る許可が与えられていることを示すデジタル署名を提供する権限機関要素、（３）デジタル署名を受け付けてそれを提示できるカードまたはその他の有線／無線装置、である。

アクセスの許可は下記の一連の手順のいずれかによって付与できる。

手順１；
（１） 権限機関要素が、許可を与える署名をカードに受けさせる；
（２） カードは、許可を与える署名を受け取って保存する；
（３） カードは、許可を与える署名をドアに提示し、ドアは、それを検証し、許可を与える署名が有効であり、かつその場合に限り、開く。

手順２：
（１） カードは、アクセス許可を求めてそのカード自身をドアに提示する；
（２） ドアは、許可を与える署名を要求する；
（３） 権限機関要素が、ドアに、許可を与える署名を受け取らせる；
（４） ドアは、許可を与える署名を検証し、それが有効であり、かつその場合に限り、開く。

手順３：
（１） カードは、権限機関要素からの許可を与える署名を要求する；
（２） 権限機関要素は、許可を与える署名をカードへ送る；
（３） カードは、許可を与える署名を受け取って保存する；
（４） カードは、許可を与える署名をドアに提示し、ドアは、それを検証し、許可を与える署名が有効であり、かつその場合に限り、開く。

手順４：
（１） ドアは、（それ自身の求めまたは求めによらずに、）遭遇することが予測される複数のカードに対する許可を与える署名を、権限機関要素から前もって受け取る；
（２） カードは、アクセス許可を求めるドアに対し、自身を提示する；
（３） ドアは、カードの許可を求める署名を検証し、それが有効であり、かつその場合に限り、開く。

これらの手順は、多数の例のうちのいくつかにすぎない。また、これらの手順は組合わせることができる。例えば、ドアは情報／許可のある部分（例えば、２０バイト値）を受け取ることができ、カードは他の部分（例えば、デジタル証明書）を受け取ることができる。それらは時間的に隔てられることもある。カードは情報／許可のある部分（例えば、デジタル証明書）を最初に受け取り、その後で、他の部分（例えば、各時間ごとの２０バイト値）を受け取ることができる。

さらに、許可を与えるデジタル署名を、カード保持者の長期間証明書に結び付けることができる。例えば、カードは、毎年有効な長期間証明書を含むことができ、権限機関要素は、証明書が現在日に依然として有効であることを証明する毎日の署名を発行できる。

権限機関要素は、要求がなくとも許可を自動的に生成してもよい。例えば、翌日も許可されるであろう被用者に対する許可を与える署名を、権限機関要素は毎晩発生できる。こうすることによって、権限機関要素を非対話（ノン−インタラクティブ）型とすることができ、したがって、セキュアに構成することがより容易となる。

また、権限機関要素は、許可を与えるための署名をカードとドアの少なくとも一方に普及させるために、別々のおそらく安全でない装置を使用できる。これによって権限機関要素は、ただ１つのタスク、すなわち、許可の発生、に的を絞ることを可能にされる。それにより、セキュアな権限機関要素と（おそらくよりセキュア（安全）でない）ドアおよびカードとの間の面倒な直接接続の必要が除かれる。特に、許可を与えたことの知らせ(dissemination)は、次のようにして行われる。（１）権限機関要素が許可を発生する、（２）権限機関要素は、許可を、おそらく安全でない接続を介して、普及データベース(dissemination database)へ送る。それらのデータベースは多数の場所に設けることができ、安全である必要はない。例えば、５か所の従業員入口がある会社では、各入口に１つの普及データベースが存在することがある。（３）普及データベースは、許可を、要求に応じて（引く(pull)）または自動的に（押す(push)）、カードとドアの少なくとも一方へ送る。

上記方法を可能にする特性は、許可自体は忘れ去ることできない、すなわち、権限機関要素によってのみが発生できる、ということである。したがって、ひとたび発生されると、セキュリティに対する何等のリスクもなしに、信頼できない線および装置を通じて、許可を与えたことを知らせることができる。これにより、他のいかなる者や装置も権限機関要素と対話する必要が避けられ、その結果として、セキュアな接続を要する他のいかなる解決策よりも安価な解決策が得られることになる。

実際に、このシステムにおけるいかなる構成要素の間の接続も、セキュアにする必要はない。（不適切な許可は行われないように、権限機関要素自体のみをセキュア（安全）にする必要がある。）そうすると、障害に強い(fault-tolerant)、分散アクセス許可基盤をはるかに容易に構成できる。さらに、上記のように、ドアに何等の接続も必要とすることなく、基盤(infrastructure)を構成することが可能である。

本発明のアクセス管理システムは、第３章のテナントＣＡに組合わせることができることを理解すべきである。例えば、保護されている種々の区域に対する、証明書の保持者がアクセスできる能力を個々に管理しながら、いくつかの権限機関（例えば、事務所ビルにおける、駐車場権限機関、クリーニング権限機関、またはビル内で共同使用している複数の企業）が同じ証明書を利用できる。

例６：
このシステムは、次のようにして動作できる。ユーザＵ（または彼のカード）が、対象とする各ドアＤについてのバリデーション（有効性検証）フィールド（例えばＤ３６５）を含む証明書ＣＥＲＴを有する。ｊ日にＵがドアＤを通ることができることについての許可は、忘却できない２０バイト値Ｘ３６５‐ｊを発行ことにより示すことができる。ドアＤは、ｊ回、それにハッシュ関数を適用し(hashing)、結果がＣＥＲＴのバリディティ（有効性）フィールドＤ３６５に合致するかどうかを調べることにより、許可を調べることができる。Ａが複数のドア（例えば、１０００のドア）を取り扱わねばならない場合には、ＣＥＲＴは、おのおのが異なるドアに対応する１０００の異なるバリディティフィールドを含むことがあり、各ドアＤｊは、それの計算結果をｊ番目のバリディティ・フィールドと比較して調べる。この場合には、あるユーザに対する各ドアを通る許可が別々に証明されたとしても、各ユーザは、ある所与の日には、たかだか１０００の証明を持つだけである。そうすると所与の日には、たかだか２０Ｋバイトを彼のカードにロードする必要があるだけである。

ここではカードは一般的なカードであるから、カードは非接触カードにでき、カード読取器は受信機とすることができ、かつカードは読取器に挿入する必要はなくて、それへ送信すれば良いことに注目されたい。そのような無線カード‐読取器の相互作用（インタラクション）は依然として全く局所的なものであり、Ａまたはデータベースが遠く離れている場合のカードと権限機関／データベースとの相互作用とは非常に異なることに注目されたい。

さらに、許可を与えるデジタル署名は、カード保持者の長期間証明書(long-term certificate)に結び付けることができる。例えば、カードは毎年有効な長期間証明書を含むことができ、権限機関要素は、証明書が現在日にも依然として有効であることを示す毎日の証明書を発行することできる。

権限機関要素は、何等の要求もなしに、許可を自動的に出すことができる。例えば、権限機関要素は、翌日に許可されるであろう被用者に対して、許可を与える署名を発行できる。このやり方によって、許可構成要素を対話（インタラクティブ）型ではなくすことができ、したがって、セキュアに構成することがより容易になる。

実際に、このシステムにおけるいかなる構成要素の間の接続もセキュアにする必要はない。（不適切な許可は与えられないように、権限機関要素自体のみをセキュアにする必要がある。）そうすると、障害に強い、分散アクセス許可基盤をはるかに容易に構成できる。さらに、上記のように、ドアに何等の接続も必要とすることなく、そのような基盤を構成することが可能である。

本発明のアクセス管理システムは、上記のテナントＣＡに組合わせることができることを理解すべきである。例えば、保護されている種々の区域に対する、証明書の保持者がアクセスできる能力を個々に管理しながら、いくつかの権限機関（例えば、事務所ビルにおける、駐車場権限機関、クリーニング権限機関、またはビル内で共同使用している複数の企業）が同じ証明書を利用できる。

非接続のドアへのアクセスの証明の記録(logging)：
（権限機関およびデータベースから）切り離されていてしかも非常にセキュアで、低コストかつ便利なスマートドアは、接続されているスマートドアにとっては好ましいが、後者は、所与のドアに対するアクセスを記録するする能力を与える。例えば、所与の日に所与のドアを誰が通ったかを知ることが重要なことがある。接続されているドアは、適切な「アクセス情報」を離れているデータベースまたは権限機関に送ることによって、それを容易に行うことができる。しかし、非接続のドアはそれを全く行うことができない。そのような情報を集めるために適切な人をドアからドアへ送ることにより、アクセス情報を集めることができる。これを行うことが常に便利であることはないかもしれない。しかし、下記のシステムは、非常に実行可能な代替技術を提供するものである。

ユーザＵが時刻ｔにあるドアＤを通る（または通ろうとする）と、ドアは適切な文字列ＬＯＧＵＤｔを発生し、それを（少なくとも一時的に）ローカルに保存する。この情報が適切なデータベースに確実に到達するようにするために、ドアは、それを通るために使用されるカードを使用できる。例えば、ＤはＬＯＧＵＤｔを（おそらくＵ自身も含む）他の（単数または複数の）ユーザＵ’のカードに書込む（またはＬＯＧＵＤｔが書込まれるようにする）ことができる。Ｕ’がＰＲ（例えば、翌日の作業）または有線接続されまたは良く接続されている他の装置への接続を行うと、ＰＲまたは前記装置は、ＬＯＧＵＤｔを適切なデータベースへ送る。このようにして適切なデータベースは、ＬＯＧＵＤｔを最終的に受け取り、それを容易に検査できるやり方で、より長い期間にわたって、保存する。おそらくデータベースはＬＯＧＵＤｔの冗長なコピーを受け取るが、望まれないいかなる冗長部も除去し、正本(clean copy)のみを保持することは容易である。

好ましいＬＯＧＵＤｔは、Ｕ自体のデジタル署名からなるもの、またはその署名を含んでいるものである。こうすると、Ｕは、容易には、彼が所与の時刻に所与のドアを通ったこと否定してドアのアクセス情報は偽造されたものであると主張できない。実際に、彼のみが、ＬＯＧＵＤｔを発生する秘密署名鍵を持っているのである。例えば、ＬＯＧＵＤｔは、Ｕが時刻ｔにドアＤを通ったことを示すＳＩＧ_U(Ｄ，ｔ)よりなる。ユーザＵのカードに、公開鍵ＰＫＵに適合する秘密署名鍵ＳＫＵが記録されているならば、それを行うことは非常に容易である。カードがＰＫＵのためのデジタル証明書を保持することが好ましく、したがって、ＬＯＧＵＤは、ＳＩＧ_U(Ｄ，ｔ)ばかりでなくＵの署名も含むことができる。また、ユーザカードは、それ自身のクロックによって示された時刻ｔに従って、ＳＩＧ_U(Ｄ，ｔ)を生ずること、およびドアは、（上述したもののような許可が与えられたことの他の証明に加えて）Ｕがそのような良いアクセス証明ＳＩＧ_U(Ｄ，ｔ)を提供した後で、かつＵにより保証された時刻がドアクロックにより計られた現在の時刻ｔ’に十分近い場合のみ、Ｕを通させることができることも好ましい。なおまたユーザは、彼が時刻ｔにドアＤを通ったがそのドアはどこか全く他の場所であり、したがって、ＳＩＧ_U(Ｄ，ｔ)は彼が所与の建物の例えば３階の２番目のドアを通ったことを全く証明しない、他の誰かがドア読取器等をその場所に送ったに違いない、と主張することができる。このような主張を避けるために、またはユーザをそのようなだまし行為から守るために、ユーザカード（装置）はＧＰＳ機構を包含していてもよく、ＳＩＧ_U(Ｄ，ｔ)は、カードにより測定されるローカル位置ｌｐを実際に含んでもよい。その場合には、ユーザは、アクセスの証証明ＳＩＧ_U(Ｄ，ｔ，ｐｓ)をドアに送ることができ、ドアはそれを受けて、時間が正確に見えるばかりか、ローカル位置も正確である場合にのみユーザを通す。カード／装置の内部でｐｓを計算するのではなくて、ユーザは、ユーザが信頼し、かつ、ユーザから受け取った情報（およびおそらくそれ自身の位置）からユーザの位置を計算できる、なにか１つまたは複数の構成要素を使用できる。

実装：
基本システム：
図１から分かるように、ＣＡは、そのＣＡが発行したがまだ失効していない証明書Ｃ₁，...，Ｃ_kのおのおのについて、個々の証明書無効状態情報ＣＲＳ_iをディレクトリへ送る。ディレクトリは、ＣＲＳ_iを、その認証局の証明書一連番号「ｉ」について尋ねた要求しているユーザへ送る。

標準証明書フォーマット（例えば、Ｘ．５０９ｖ３）で動作して、認証局（ＣＡ）が、Ｃの発行日Ｄ₁から始まる任意の時間間隔（例えば、毎日、毎時、または毎分）に各証明書Ｃの有効性状態を証明することを可能にするデジタル証明書有効性検証プロセスによって物理アクセスを管理するシステムおよび方法を開示する。Ｃの時間粒度は、全ての証明書に対して同じでないならば、証明書自身内で指定できる。具体的には、限定することを意図することなしに、以下では、全ての証明書に対して時間粒度を１日とし、各証明書は発行の３６５日後に失効するものと仮定する。

証明書Ｃの作成：一連番号ＳＮ、公開鍵ＰＫ、ユーザ名Ｕ、発行日Ｄ₁、失効日Ｄ₂（＝Ｄ₁＋３６５）などの従来の量に加えて、証明書Ｃは、それに一意の２つの２０バイト値も含む。特に、証明書Ｃを発行する前に、ＣＡは、２つの異なる２０バイト値Ｙ₀，Ｘ₀を無作為に選択し、それらから２つの対応する２０バイト値Ｙ₁，Ｘ₃₆₅を、下記の特性を持つ一方向ハッシュ関数Ｈを用いて計算する。それらの特性とは次のようなものである。Ｈは、デジタル署名を計算するよりも最低１００００倍速い、Ｈは、それの入力がどれだけ長くとも２０バイト出力を生ずる、Ｈは、逆演算が困難である。Ｈは逆演算が困難であるということは、Ｙが与えられると、Ｈ(Ｘ)＝ＹであるようなＸを見出すことが実際には不可能であるということである。（例えば、１９９４年７月１１日に改定され（Federal Register（連邦公報）, Vol. 59, No. 131, pp. 35211-34460）、１９９４年８月５日に改定された（Federal Register, Vol. 59, No. 150, pp. 39937-40204）、Secure Hash Standard（セキュアなハッシュ規格）;FIPS PUB 180、参照。）値Ｙ₁はＹ₀を１回ハッシュすることにより計算される、すなわち、Ｙ₁＝Ｈ(Ｙ₀)。Ｘ₃₆₅はＸ₀を３６５回ハッシュすることにより計算される、すなわち、Ｘ₁＝Ｈ(Ｘ₀)，Ｘ₂＝Ｈ(Ｘ₁)，...，Ｘ₃₆₅＝Ｈ(Ｘ₃₆₄)である。Ｈは常に２０バイト出力Ｙ₁，Ｘ₃₆₅を生ずるので、全ての中間値Ｘ_jは２０バイト長である。値Ｙ₀，Ｘ₀，Ｘ₁，...，Ｘ₃₆₄は秘密に保たれ、Ｙ₁，Ｘ₃₆₅は証明書に含まれる。すなわち、Ｃ＝ＳＩＧ_CA（ＳＮ，ＰＫ，Ｕ，Ｄ₁，Ｄ₂，...，Ｙ₁，Ｘ₃₆₅）である。Ｙ₁のことを無効(revocation)ターゲットと呼び、Ｘ₃₆₅のことを有効性ターゲットと呼ぶことにする。

まだ失効になっていない証明書Ｃを無効にし検証する：Ｃの発行のｉ日後（すなわち、Ｄ₁＋ｉ日）に、ＣＡは、Ｃの状態の２０バイト証明を次のように計算して出力する。Ｃが無効にされたとすると、Ｃの無効の証明として、ＣＡはＹ₀、すなわち無効ターゲットＹ₁のＨ逆変換を出力する。さもなければ、その日におけるＣの有効性の証明として、ＣＡはＸ_365-iを、すなわち有効性ターゲットＸ₃₆₅のｉ番目のＨ逆変換を出す。（例えば、発行１００日後のＣが有効である証明はＸ₂₆₅よりなる。）ＣＡは、質問に答えてその値を提供することにより、またはワールド・ワイド・ウエブ(World Wide Web)へそれを送り出すことにより、それを登録することができる。

まだ失効になっていない証明書Ｃの状態の検証：いつの日でも、Ｃの無効の証明Ｙ₀は、Ｙ₀を１回ハッシュし、その結果がＣの無効ターゲットＹ₁に等しいことを調べることにより検証される。（すなわち、検証者は、Ｙ₀が実際にＹ₁のＨ逆変換であることを調べる。）なお、Ｙ₁はＣ内で証明されているので、Ｙ₁はＣの無効ターゲットであることが保証されている。Ｃの発行からｉ日後に、その日におけるＣの有効性証明Ｘ_365-iは、値Ｘ_365-iをｉ回ハッシュし、その結果がＣの有効性ターゲットＸ₃₆₅と等しいかどうかを調べることによって検証される。（すなわち、検証者は、Ｘ_365-iが本当にＸ₃₆₅のｉ番目のＨ逆変換であるかを調べる。）検証者は、（Ｄ₁はＣ内で証明されているので）現在の日にちＤとＣの発行日Ｄ₁を知っており、したがって、ｉ＝Ｄ−Ｄ₁をただちに計算することに注目されたい。

セキュリティ：
無効の証明は偽造できない：証明書Ｃの無効の証明は、Ｃの無効ターゲットＹ₁のＨ逆変換よりなる。Ｈは、本質的に逆演算不可能であるので、所与の２０バイト値Ｙ₀が確かに無効のＣの証明であることを検証者がひとたび調べると、Ｙ₀はＣＡから出たに違いないことを検証者は知る。実際に、ＣＡのみがＹ₁のＨ逆変換を計算できる。その理由は、ＣＡがＨを他のいずれよりもうまく逆演算できるからでなく、ＣＡが、Ｙ₀で始まってそれをハッシュすることによりＹ₁を計算したからである！ Ｃが有効である限りはＣＡはＣの無効証明を決して外に出さないので、敵は無効証明を偽造できない。

有効性の証明は偽造できない：ｉ日において、証明書Ｃの有効性の証明は、Ｃの有効性ターゲットＸ₃₆₅のｉ番目のＨ逆変換数よりばる。Ｈは、本質的には逆演算不可能であるので、所与の２０バイト値Ｘ_365-iがｉ日での確かにＣの有効性の証明であることを検証者がひとたび調べると、検証者は、ＣＡがＸ_365-iを出したに違いないことを知る。実際に、ＣＡのみがＸ₃₆₅のｉ番目のＨ逆変換を計算できる。その理由は、ＣＡがＨを他のいずれよりもうまく逆演算をできるからではなく、ＣＡがＸ₀で始まってそれを３６５回ハッシュすることにより、Ｘ₃₆₅の初めの３６５個の逆変換の全てをずっと計算するからである！ ｉ＋１日に証明書Ｃが無効にされるようになったとすると、ＣＡは先き立つｉ日（Ｃが依然として有効である時）中に、値Ｘ３６５−１，...，Ｘ_365-iを既に外に出しているが、値Ｘ_365-i-1（または他の任意の値Ｘ_j、ただしｊ＜３６５−ｉ）を外に出しておらず、かつ、将来においても決して外には出さないであろう。したがって、ｉ＋１日に有効性証明を偽造するためには、敵は、Ｘ₃₆₅のｉ＋１番目のＨ逆変換（すなわち、Ｘ_365-iのＨ逆変換）を自分自身で計算しなければならないが、それは実行が非常に困難である！ 同様に、敵はｉ＋１日の後の任意の日でＣの有効性証明を計算できない！ そうするためには、再び入力Ｘ_365-iに対してＨを逆演算できなければならない。例えば、ｉ＋２日にについてのＣの有効性証明Ｘ_362-i-2を計算できるものとすると、それを１回ハッシュすることにより、Ｘ_365-i-1すなわちＸ_365-iのＨ逆変換が容易に得られる。

効率：
証明書Ｃはただ２つの付加的な２０バイト値Ｙ₁，Ｘ₃₆₅を含む：これは無視できるコストである。Ｃは、公開鍵ＰＫ（少なくとも１０２４ビット長）を含んでいるデータのＣＡ署名（少なくとも２０４８ビット長）で既に構成されていること、およびＣは、ＳＮ，ＰＫ，Ｕ，Ｄ₁，Ｄ₂に加えて、コメントや多数の他のデータを含むことができることを想起されたい。

Ｙ₁とＸ₃₆₅の発生には全部で３６６回のハッシングを要するのみである：これもまた、無視できるコストである。証明書を発行することは、既に、署名を計算することを要することを想起されたい。

無効の証明と有効性の証明は２０バイト長に過ぎない：我々の２０バイト証明は、伝送のためにはささいなことであり、保存のためにもささいなことであって、２０バイト技術を無線用途にとって理想的なものにする（ここでは帯域幅が依然として限定されており、そのために多くの携帯電話およびその他の無線装置の記憶容量が限定されているからである）。

本発明の実施形態に基づく証明は、それのセキュリティを、指数関数的なセキュリティ量を必ず示す一方向関数などの、基本的な暗号化構成要素から得ているので、非常に短くできる。（全く異なることに、デジタル署名技術は複雑なセキュリティ諸要求を持つ。それらの典型的な数理的実現によってせいぜい準指数関数的な安全度を提供するのみであるので、はるかに長い鍵を必要とする。）
証明は、証明書の総数が数百または数十億であっても、２０バイト長のままである。実際に２¹⁶⁰個もの可能な２０バイト列があり、２つの証明書が共通の無効証明または有効性証明をたまたま持つ確率は無視できる。

あた、我々の２０バイト証明の長さは暗号化または認証のために増大することはないことに注目されたい。我々の２０バイト証明は公開することを意図されているので、暗号化する必要はない。同様に、我々の２０バイト証明は自己認証であり、それらを適切な回数ハッシングすることにより、証明書で指定されている有効性ターゲットまたは無効ターゲットを生ずる。それらは偽造されたり変更されても機能しないので、いかなる態様でも署名したり認証したりする必要はない。

最後に、ｉ日の２０バイト有効性証明Ｘ_365-iは、値ｉをさらに含む必要はない。ある意味では、それはそれ自身の時間スタンプを既に含んでいる！ 実際に、前に説明したように、ｉは現在日と証明書の発行日との間の差であり、Ｘ_365-iをｉ回ハッシングすると証明書Ｃの有効性ターゲットが生じ、その後でこれはＸ_365-iがｉ日におけるＣのバリディティ証明を証明する。

２０バイト証明は即時に計算される：無効証明Ｙ₀または有効性証明Ｘ_365-iはメモリからまさに検索される。（あるいは、各Ｘ_365-iはｉ日に実行中に再計算できる。例えば、Ｘ₀が証明書の発行中に保存されているならば、たかだか３６４回のハッシングにより、再計算される。驚くべきことに、より効率的な戦略を次の節で説明する。）
無線環境：
本発明の実施形態は、無線による実現のために理想的である。それのスケーラビリティは極めて大きい。すなわち、それは何十億という証明書(cert)を極めて容易に取り扱うことができる。それが求める帯域幅は無視できて、質問に対してはほぼ３０ビット一連番号、応答に対してはほぼ２０バイトである。それが求める計算は無視できる。その理由は証明書状態質問が単一のテーブルのルックアップ（検索）で回答されて、ただちに検証されるからである。もちろん、大きなスケーラビリティと、最小の帯域幅と、些細な計算とによって、本発明は無線環境における選択される技術にされる。

しかし、本発明には、無線用途において付加的な利点をもたらす別の用途もある。すなわち、毎朝ごとに、例えば、真夜中に、無線ユーザは、その日のうちの残りの部分についての彼の証明書の２０バイト有効性証明を受けることがある。（この２０バイト値は、ユーザの求めに応じて得ることができ、または、例えば、ＳＭＳメッセージまたはその他の制御メッセージによって、ユーザの携帯装置へ自動的に送ることができる、）それの短い長さのために、この証明は、ほとんどの携帯電話およびＰＤＡに容易に保存できる。その後で、ユーザがその日に処理することを望む時は、常にユーザはそれ自身の証明書をその日の証明書(cert)の２０バイト有効性証明と一緒に送るだけである。有効性証明は例外なく検証できるので、証明書(cert)の検証者と証明はいかなるＣＡまたはいかなる応答側も呼び出す必要はない。検証者は完全にオフラインで機能できる。いかなる呼び出しも金額と時間費用に換算される携帯電話環境では、このオフライン性能は極めて価値がある。

ＯＣＳＰとの比較：
本発明およびＯＣＳＰは、ともにオンデマンド・システム、すなわち、ユーザが証明書の現在の有効性についての質問を送り、偽造不能で例外なく検証できる証明を折り返し受けるシステム、である。しかし、時間確度、帯域幅、ＣＡ効率、セキュリティ、および運用費には違いがある。

時間確度：原則として、ＯＳＣＰ応答は、幅が限られていない確度で時刻を指定し、本発明の好適な実施形態の応答は、所定の確度（１日、１時間、１分等）で時刻を指定する。小さい値の応用では、１日間だけの有効は、十分許容できる。ほとんどの金融用途では、デジタル署名トラストは、４時間の確度で十分であると考えている。（おそらくこれは、それが見えるよりも驚きが小さい。ほとんどの金融トランザクションでは、午前に受けた注文は午後に実行され、午後に受けた注文は次の営業日に実行される。）いずれにしても、時間は、無限に多くの桁の実数によって指定されることはない。オンデマンド有効性検証システムでは、１分より小さい時間確度はほとんど無意味である。その理由は、質問者のクロックと応答側のクロックは同期されていないことがあるからである。実際に、そのようなシステムでは、１５秒という時間確度は、事実上、リアルタイム（実時間）ということである。

そのような極端な確度を取り扱うために、本発明の好適な実施形態は、ほぼ１Ｍ長であるハッシュチェーンを計算する（すなわち、Ｘ_1M型のバリディティ・フィールドを計算する必要がある）。その理由は、１年がたかだか５２７０４０分だからである。そのような長さのチェーンを効率よく取り扱えるものとすると、本発明の好適な実施形態は、事実上、リアルタイムである。１Ｍハッシングの計算は、証明書発行のためには問題はなく、１Ｍハッシングは、非常に妥当なプラットフォームを用いたとしても、１秒以内で実行でき、証明書は通常１年に１回、厳しい時間的な圧力を受けずに、発行される。同様に、証明書(cert)有効性証明の検証者（例えば、証明書に頼っている商人）が、一般に個々の取引だけに注意を払って、使える時間がいつでも多いことを考えると、検証者にとっては１秒間の計算は問題ではない。しかし、証明書状態要求ごとに１Ｍハッシングを計算することは、有効性証明を生ずるサーバの性能に影響を及ぼす。その理由は、それが１度に多数のトランザクションを取り扱うのが普通だからである。幸いなことに、このサーバはそれらのハッシングの全てを、Ｘ₀から始めてオンラインで計算する必要はなく、記憶装置中にあらゆる証明書の全ハッシュチェーンの保存していることを利用して、表の検索により行う。けれども、１Ｍ長さのハッシュチェーンを保存することは、巨大な数の証明書を取り扱う用途では、問題があるかもしれない。しかし、幸いなことに、後で説明するように、通常のサーバでも、より良いアルゴリズムを用いて、１Ｍ長さのハッシュチェーンを驚くべき効率で再計算できる。

帯域幅：本発明の好適な実施形態は、ＯＣＳＰより明らかな帯域幅利点を有する。前者は２０バイト応答を使用し、後者は、通常、２５６バイトを使用する。

ＣＡ効率：バリディティ質問は、ＯＣＳＰの場合には、（複雑な）デジタル署名により応答され、本発明の場合には、ＣＡが各証明書に対するＸチェーン全体を保存する限り、（ささいな）表検索により応答される。

百万個の証明書の場合では、ＣＡは、時間確度が１日または１時間の場合に、各証明書についてＸチェーン全体を保存することができることに注目されたい。（最初の場合には、ＣＡは３６５個の２０バイト値、すなわち、証明書(cert)当り７．３Ｋバイト、したがって、全体で７．３Ｇバイト、を保存しなければならない。第２の場合には、全体で１７５．２Ｇバイト。）時間確度が１５秒であるとすると、各ハッシュチェーンは、１Ｍ個の２０バイト値よりなり、システム全体に関して、全体の記憶装置に対する要求は、約１０．５テラバイトである。これは相当大きな記憶装置である。

この記憶装置に対する要求を劇的に減少するために、ＣＡは、各証明書ごとにちょうど１つの２０バイト値（すなわち、Ｘ₀）を保存でき、たかだか１Ｍハッシングにより各Ｘ_i値をそれから再計算できる。あるいは、ヤコブソン(Jacobsson)［５］は、時間と記憶装置の驚くべき二律背反性を見出した。すなわち、ＣＡは、ｌｏｇ (ｎ)ハッシュ値を保存し、ｌｏｇ (ｎ)ハッシングを毎回行うことにより、ｎ個のＸ_i値を全て、右順に、再計算できる。ｎが１Ｍであるならば、これは証明書(cert)ごとに２０個のハッシュ値をちょうど保存し、２０回だけのハッシングを証明書(cert)がバリデーションを必要とするたびに行うことを意味する。その他のささいでない二律背反性も可能である。特に、我々の１Ｍチェーンの場合では、レイジン(Reyzen)［Ｒ］が、ＣＡはただ３つのハッシュ値を保存し、たかだか１００のハッシングを毎回行うことにより全てのＸ_i値（ｉ＝１Ｍから１まで）を計算できることを示している。

要するに、事実上のリアルタイム用途（すなわち、１５秒時間確度を用いる）でも、本発明の好適な実施形態は、証明当り６０バイトを保存するのみで、複雑なデジタル署名操作をささいな１００回のハッシュ操作に置き換えることができる。

セキュリティおよび運用経費：最後の２つの違いは、本発明の好適な実施形態および考察しているＯＣＳＰの実施の形式を指定した後でより良く説明する。

集中化した実装：セキュリティ分析：
証明書の有効性を証明することが所与の鍵の秘密性に依存する場合は、システム全体の一貫性を保障するために、セキュアな金庫(vault)がその鍵を守らねばならない。本発明の好適な実施形態で、またはＯＣＳＰによって、集中化した実装というのは、単一の金庫が全ての有効性に関する質問に答えるものであることを意味する。集中化した実装は、展開されている証明書の数が小さい（例えば、１００Ｋを超えない）ならば好ましく、したがって、金庫は、短い時間間隔内にほとんど全ての証明書が用いられて、有効性についての質問をほとんど同時にトリガするものとしても、発生された質問の量を取り扱うことができる。そのような実装では、好適な実施形態は、下記のような面でＯＣＳＰにとっては好ましい。

永久的な保護(Doomsday Protection)：従来のＯＣＳＰでは、（金庫および固められているガードにもかかわらず）敵が金庫内への浸透を続けて秘密署名鍵を危うくした(compromise)とすると、彼は以前に無効にされた証明書を「復活する」ことと、依然として有効なものを「無効にする」ことができる（ＣＲＬ署名鍵がＣＲＬシステムで危うくした場合も同様である。）対照的に、本発明の好適な実施形態では、セキュアな金庫に浸透しても、以前に無効にされたいかなる証明書のバリディティを偽造する敵を支援することはない。実際に、証明書がｉ日に無効にされるようになると、それの無効証明Ｙ₀が公開されるばかりでなく、同時に、それの全てのＸ_i値（値Ｘ₀〜Ｘ_365-i）が削除される。したがって、危うくすることに成功した後では、敵は彼が無効にされた証明書の「バリディティを拡張」できるようにするものは何も見付けない。そうするために、彼はＸ_365-iについての一方向ハッシュを何等の支援も無しに続行せねばならない。それは試行することを彼が歓迎する（およびいかなる秘密金庫にも入ることなく確かに続行できる）ものである。危うくすることに成功した後で本発明のシステムで敵が行うことができる最悪のものは、有効な署名の無効を偽造して、正直なユーザが合法的なトランザクションを行えなくすることである。もちろん、これは悪いことであるが、不正直なユーザが非合法なトランザクションを認証できるようにするほど悪いことではない。

分散化実装：セキュリティおよび運用経費分析：
集中化実装は、証明書の有効性（バリディティ）についてのあらゆる質問を同じ金庫へ経路指定することを求める。この結果として遅延が長くなることと、何百万というアクティブな証明書での用途におけるサービス拒否が容易に起きる。そのような混雑、遅れ、およびサービスの拒否を防止するために、バリディティ質問に対する応答の負荷を地理的に分散されているいくつかの応答サーバの間に拡げることもある。しかし、ＯＣＳＰの場合には、各付加応答サーバは秘密署名鍵を持つ必要があり、したがって、金庫において主人役を努める必要があり、そのためにＯＣＳＰシステムの所有費用が非常に莫大なものとなる。金融機関の諸要求に合致する高度の金庫の経費は、構築に最低１Ｍドル、運用に最低１Ｍドルを要する。（良い金庫は装甲コンクリート、鋼鉄製のドア、バックアップ用発電機、潜在的に長時間運転する発電機用の防護された燃料貯蔵容器等を含む。それの運用には２４Ｘ７Ｘ３６５運用のための最低４組のチームと、プラス管理監督等を含む。）ピークトラヒック時にかなり速い応答を保障するためにそのような金庫を１０要する用途では、ＯＣＳＰシステムを所有する費用は初期投資で１０Ｍドルであり、運用予算は１０Ｍドル／年であろう。より安全でない金庫および運用が用いられるとしても、何百万ドルという初期費用と運用費を依然として必要とする。

しかし、本発明の好適な実施形態の場合には、分布実施は単一の金庫（ＣＡがともかく有するであろう）と、任意の数の「信頼されていない応答側」（すなわち、通常のサーバ）で達成できる。（ａ）１０Ｍの証明書(cert)が存在する、（ｂ）応答時間を短縮するように地球の周囲に戦略的に配置されている１０００のサーバが存在する、（３）時間の粗さが１日、であると具体的に仮定して、分布システム実際の詳細を見ることにする。

ＣＡの運用（初期設定費用）：毎朝、最小一連番号かた始まって１０Ｍエントリ・アレイＦを次のようにコンパイルする。一連番号ｊを持つ各証明書に対して、Ｃの２０バイトバリディティ／無効証明を場所ｊに保存する。その後で、日付と署名Ｆをし、それを１０００のサーバのおのおのへ送る。

ユーザ操作（質問経費）：証明書Ｃの状態を知るために、Ｃの一連番号、ｊ、（および必要があればＣＡ ＩＤ）をサーバＳへ送る。

サーバ動作（応答費用）：毎朝、適切に日付をつけられて署名されたＦが受けられると、古いアレイを新しいものと置き換える。

いつでも：２０バイト値を現在のＦの場所ｊへ戻すことにより一連番号ｊについて質問する。

好適な実施形態の動作
１．アレイＦの準備は即時である：
各証明書(cert)についてハッシュチェーンが保存されるとすると、その後で各エントリが単なる表検索操作で計算される。他の実施形態では、それはただちに計算もできる。

２．Ｆが秘密を含んでいない：
それはどの証明書が依然として有効であるかおよびどれが無効にされたについての完全かつ十分な報告より成る。（ＣＡの目標はこの秘密でない情報を最も効率的なやり方でできるだけ公開のものと確かにすることである）
３．Ｆをサーバへ転送することは直接的である：
これがそうである理由は、Ｆが秘密を含んでおらず、暗号化を要せず、セキュリティの危険を持たないからである。１０Ｍ証明書(cert)は多数であるが、２００Ｍバイトのファイルを１０００のサーバへ一定の間隔で送ることは非常に行えることである。

４．各サーバの応答の長さは２０バイトである：
また、各応答は暗号化、署名または時刻記録を必要としない。

５．合法的なユーザに対するサービスの拒否はない：
送られる各値は調度２０バイト長であ利、そのような各値はただちに計算され（表の検索により）、かつトラフィックを１０００のサーバの間で分散できるので、少なくともシステムの合法的な使用中は、サービスの拒否は起きるはずがない。

６．サーバは信頼される必要はない：
それらはＣＡにより受けられた２０バイト証明を転送するのみである。自己認証であるので、それらの証明は変更でききず、関連するターゲットに依然としてハッシュする。

本発明の分布型実施はそれの集中型実施の同じ永久的な防護を受け続ける。すなわち、金庫に侵入することに成功した敵は無効にされた証明書を受けることができない。しかし、巧妙な敵は金庫に孔を開けることはせず、可能な場合には何時でもソフトウエアによる攻撃を選ぶ。幸いなことに、ソフトウエア攻撃は、分布／集中ＯＣＳＰに対して可能ではあるが、本発明の分布実施に対してはたち向かうことはできない。

ＯＣＳＰでは、実際に、ＣＡは信用されないものからの外部質問を受けること、およびデジタル署名によって、したがって、それの貴重な秘密鍵により、それらの質問に答えることを求められる。したがって、秘密署名鍵を明らかにするために、ＯＣＳＰの求められている「外界に向いた窓」を悪意をもって利用される可能性が存在する。

対照的に、本発明の分布実施にはそのような「窓」はない。ＣＡは金庫内にあり、外部からのいかなる質問も受けないか、質問に答えず、秘密でないデータを周期的な間隔で出力するのみである。たしかに、毎日（または毎時）それは公開情報より成るファイルＦを出力する。（ＣＡは無効要求をそれのＲＡから受けるかもしれないが、それらはより少数の信用ある実態から認証されているチャネルを経由して来る‐‐例えば、セキュアなスマートカードを用いて。）信用されない応答側は信用されないものからの質問を受けるが、彼等はそれらの質問に彼等のファイルＦによって、したがって、公開データによって、答える。したがって、ソフトウエア攻撃では、本発明の好適な実施形態戸は異なって通常の追う当社は公開情報を「明らかにする」のみかもしれない。

簡略化したＰＫＩ管理：
ＰＫＩ管理は些細なことではない。（例えば、S. Farrell, A. AdamsおよびW. Forward, "Internet Public Key Infrastructure, Part III: Certificate Management Protocols), Internet Draft（インターネット公開鍵基盤、第III部：証明書管理プロトコル；インターネット・ドラフト）"，１９９６年、及び、S. Kent, J, Linn, "Privacy Enhancement for Internet Electric Mail‐Part II: Certificate‐Based Key Management（インターネット電子メールのためのプライバシー増強：第II部：証明書をベースにした鍵管理）"，１９８９年参照）。本発明の好適な実施形態は、（１）発行される証明書の数を減らす、（２）証明書(cert)についての特別管理を可能にする、（３）登録機能を多数の独立しているＣＡと共用する、ことにより多くの用途でＰＫＩ管理を改善できる。

ＰＫＩ管理におけるそれらの改善を一連の特定の例によりざっくばらんに説明することにする。（１つの例で使用される諸機能および諸技術は他の例で容易に使用できることに注目されたい。無数の可能な変型例について説明することを避けるためにこれを明らかに行うことはしない。）
証明書を使用可能／使用不能にする（およびそれを保留する）：
例７：音楽のダウンロード：
インターネット音楽販売者は、それの１０００のサーバからユーザが望むいかなる歌も１日１ドルの料金で利用者がダウンロードすることを望む。これはデジタル証明書で効果的に実行できる。しかし、この例では、Ｕが１年のうちのほんの僅かな日数だけ音楽をダウンロードするであろうことを彼は確信しており、しかも彼はそれらの日がいつであるか、または何日間であるのかは予測できない。したがって、音楽センターは、Ｕが１日用証明書の発行を望んだ時はいつでもＵのために異なる１日用証明書を発行する必要がある。Ｕはそのような証明書を求め、支払いまたは支払いの約束の後で、彼はそれを受取りその後でその日に１０００の音楽サーバのいずれかで使用する。しかし、１日証明書(cert)を発行するには業者と利用者の双方に僅かではない管理費がかかる。そしてそれらの費用は利用者が別の「音楽日」を楽しむことを望むたびに必ず倍加する。

好適な実施形態では、本発明はそれらの費用を次のようにして低減できる。最初に、Ｕが業者に初めて接触すると、彼に、発行日Ｄ₁＝０と、失効日Ｄ₂＝３６５と、バリディティ・フィールドＸ₃₆₅と、無効ターゲットＹ₁とが付せられた証明書Ｃが発行される。（業者のＣＡが保留フィールドをバリディティ・フィールドとして非常に構築する。無作為な２０バイト値Ｚ₀で始まり、その後で、時間の粗さが１日の場合に、それを３６５回ハッシュする。その後でそれは全ハッシュ・チェーン、またはＺ₀だけ、を保存し、あるいは、適切な時間／保存法を用いて所望の任意のＺ_iを発生できるようにする。）ｉ＝１，...，３６５日に、Ｕがその日の「１日の音楽」を求めたとすると、業者は２０バイト値Ｘ_365-iを単に出してその証明書が有効であることを示す。さもなければ、それはＺ_365-iを出してその証明書が「保留されいている」ことを示す。さもないと、それはＹ₀を出して証明書が無効にされたことを示す。選択によっては、Ｕと音楽業者が、例えば、「ｉ入力装置から始まる１週間の音楽」を利用することに合意したとすると、それらの７日間に対する２０バイト値が適切な時刻に出されるか、単一の２０バイト値Ｘ_365-i-7がｉ日に出される。

すなわち、Ｕが音楽をダウンロードしたい時は新しい１日用証明書をＵに常に与えるよりも、業者は単一の１年間有効の証明書を与える。いつでも、この単一の証明書は、適切な２０バイト値を出すだけで、１日だけ使用可能にできる。そうすると、例えば、本発明の好適な実施形態は、１日証明書を１０出す（および利用者のブラウザに組み込む）代わりに、１年３６５日のうちから１０日、たまに行われるように、使用可能にされる単一の１年間有効な証明書(cert)を発行する。業者は、使用可能にできる（例えば、３６５日のうちから１０日証明書(cert)）日数を前もって指定する証明書(cert)（例えば、３６５日のうちから１０日証明書(cert)）を発行するために上記方法を使用することもできる。それには予測可能なより多額の費用を要するので、そのような証明書(cert)は贈物に一層適する。

同じユーザに対して多数の証明書を使用可能／使用不能にする：
例８：セキュリティクリアランス管理：
デジタル証明書は実際に良く機能して適正なユーザのみがある資源をアクセスすることを保証する。原則として、証明書(cert)自体で特権を指定できる。例えば、国務省は１０の異なるセキュリティ通過レベル、Ｌ１，...，Ｌ１０を持つことができ、それは
Ｃ＝ＳＩＧ_SD（ＳＮ，ＰＫ，Ｕ，Ｌ５，Ｄ₁，Ｄ₂，...）
に似た証明書Ｃを発行することによりセキュリティレベル５をユーザに与えたということを意味する。ここに、再びＤ１とＤ２は発行日と失効日を表す。

しかし、証明書(cert)自体についての特権を指定すると証明書管理の悪夢を魅させることがある。それの特権が変わると、証明書(cert)は常に無効にする必要がある。たしかに、被用者のセキュリテレベルは、彼の／彼女の任務で変わることがある。任務は同じ年のうちでもしばしば変わる。例えば、Ｕのセキュリティ通過レベルが一時的に３に高められたとすると、国務省は元のＣを無効にして新しい証明書(cert)Ｃ’を発行する。この作業はＵしたがってＣ’が前と同様に同じ公開鍵（および失効日）を持つ、例えば、
Ｃ’＝ＳＩＧ_SD（ＳＮ’，ＰＫ，Ｕ，Ｌ３，Ｄ₁’，Ｄ₂，...）
を持つことにより多少簡単にできる。

しかし、Ｕは新しいＣ，を彼の種々の場所、すなわち、彼のデスクトップＰＣ、彼のラップトップ、彼の携帯電話、彼のＰＤＡ等、のブラウザに「挿入する」という作業に依然として直面する。ここで、ＣＡが証明書を僅かに異なる態様で再発行するという動作を行うことは１つの行為であるが、動作を行うためにユーザに依存することは全く異なる行為である！
この管理問題は、短期間有効な証明書（例えば、発行後１日で失効する証明書）が使用されるならば悪化するだけである。本発明の教示では、１日証明書(cert)国務省の雇員またはユーザＵが、より高いセキュリティレベルが必要とされる会議に出席できるようにすることがある。（Ｕが適切な携帯端末、スマートカード、または磁気ストライプカードでさ、えにそのような証明書(cert)を有しているならば、彼は、例えば、その日の会議に出席するドアを開くためにそれを使用できる。）短期間有効な証明書の用途ははるかに広く、広い範囲まで（どの点も少なくともほとんどの用途で、２４時間で失効する証明書(cert)を無効にしない）無効にすることの困難さがないので推奨されてきた。しかし、短期間有効な証明書(cert)は全ての適切なユーザのブラウザに存在するようにその証明書(cert)を発行することは、依然として管理費がかかる。

それらの管理費は本発明の好適な実施形態を使用することによって次のように低減できる。１日時間確度で十分であると仮定すると、国務省は１０のバリディティ・フィールドと１つの無効フィールドを含んでいる証明書、例えば、
Ｃ＝ＳＩＧ_SD（ＳＮ，ＰＫ，Ｕ，Ｄ₁，Ｄ₂，Ａ₃₆₅，Ｂ₃₆₅，Ｃ₃₆₅，Ｄ₃₆₅，Ｅ₃₆₅，Ｆ₃₆₅，Ｇ₃₆₅，Ｈ₃₆₅，Ｉ₃₆₅，Ｊ₃₆₅，Ｙ₁，）
をユーザに発行する。

ここに、最初のバリディティ・フィールドＡ₃₆₅はセキュリティ通過レベル１に対応し、...１０番目のバリディティ・フィールドＪ₃₆₅はセキュリティ通過レベル１０に対応し、一方、通常のように、Ｙ₁はＣの無効フィールドである。証明書(cert)Ｃは次のようにして使用される。ｎ日に、Ｕが高い地位（すなわち、証明書(cert)Ｃが依然として有効である）にあって、Ｕのセキュリティ通過レベルが５であるとすると、国務省は２０バイト・バリディティ証明Ｅ_365-nを公表する（例えば、分散ＮＯＶＯＭＯＤＯ実装ではそれの全ての応答側へ送る）。ｍ日にＵのセキュリティ通過レベルが２になったとすると、国務省はＢ_365-mを公表する。以下同様である。Ｃが無効になると（例えば、Ｕが被用者でなくなったか、Ｕの秘密鍵が暴露されたので）、国務省はＹ０を直ちに公表する（および「将来の」Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ，Ｈ，Ｉ，Ｊの値をそれの記憶装置から消去する）。

このやり方、証明書(cert)Ｃ、は、それ自身の特権を内部で指定するが、それらの特権が正常なやり方で変化すると無効にする必要はなく、ユーザは新しい証明書(cert)を彼等のブラウザにロードする必要はない。要するに、本発明の好適な実施形態はそのような最小足型を有する。すなわち、ＣＡは（多くの関連する証明書(cert)を発行、無効、再発行、するよりも）、無効にされない確率がはるかに高い（セキュリティ通過レベルの変更が無効に変えられないので）単一の証明書(cert)を極めて簡単に発行できる。その結果、より少ない証明書(cert)がこの用途で発行または無効にされ、その結果としてＰＫＩ管理がいっそう簡単になる。

要するに、本発明の好適な実施形態は１組のダイナミックに変化する特性または属性に対する複雑な証明書管理を単一の証明書（臨時の長さが最も小さい）および属性に対する単一の２０バイト値で置き換える。

テレコム社(Telecom company)が、所与の無線装置を１つのレートから別のレートへ切り替えるため、またはローミング(roaming)目的のために、例２の方法に類似する方法を使用することがある。

貸し主ＣＡおよび借り手ＣＡ：
主なＰＫＩ経費はＲＡ関数に関連させられる。確かに、ユーザＵを特定するには費用がかかる個人面接と、Ｕが正しい秘密鍵（認証すべき公開鍵ＰＫに対応する）を確かに知っていることを検証することを要することがある。このＲＡ関数を多数のＣＡの間で共用できしかもそれらが彼等自身の証明書(cert)に対する全面的な独立の管理を保持できるようにするるならばすばらしいことであろう。

例９：組織証明書
政府および巨大組織は同位の下位機関と階層的な下位機関、すなわち、部、業務単位等、で構成されている。被用者は２か所またはそれ以上の下部機関に所属させられることがある。例えば、合衆国政府では、彼はＮＩＳＴと商務省で勤務することがある。そのような所属のおのおののためにデジタル証明書を発行すると証明書の総数が莫大なものになって、ＰＫＩが複雑になる結果となり、被用者が彼／彼女の所属を失ったり、付加したりするたびに、対応する証明書(cert)を向こうにしたり、新しいものを発行することが最上である。理想的には、（１）編成は被用者にただ１つの証明書(cert)を発行する、（２）各下部機関がそれの各所属ごとに別々の証明書(cert)を発行して管理する、という対立する２つの事柄を調和させるべきである。

それら２つの対立は本発明の好適な実施形態により次のようにして調和される。まず初めに、本発明の好適な実施形態は証明プロセスをバリデーション・プロセスから切り離すことと両立し、最初のプロセスはＣＡにより管理され、第２のものはバリデ々ション権限機関（ＶＡ）により管理されることに注目されたい。例えば、時間確度を１日と仮定すると、ＣＡが一連番号ＳＮの証明書Ｃを発行する用意をひとたび行うと、それはＳＮをＶＡへ送り、ＶＡはＹ₀とＸ₀を選択し、３つ組（ＳＮ、Ｙ０、Ｘ０）を秘密に保存し、Ｙ₁とＸ₃₆₅を通常のように計算し、その後でＹ₁とＸ₃₆₅をＣＡへ戻し、ＣＡはそれらをＣ内に含む。このやり方では、ＣＡはＣを立証することを気にする必要はなく、ＣＡはユーザを特定することとＣを適性に発行すること責任を負うのみで、ＶＡはＣが有効であるか、無効にされていることを立証できる唯一のものである。この切り離しは、内部の下部組織力学を柔軟に反映する機関証明書を持つために、種々のやり方で利用できる。下記はそれらのやり方のまさにその１つであって、政府および省庁を現在行われている例でとして使用する。政府は全体としてそれ自身のＣＡを有し、各省もそうである。

対応するＣＡすなわちＣＡ¹．...，ＣＡ^kを持つｋ個の省と、１日時間確度を例とすると、政府の証明書Ｃは次の形をとる。

Ｃ＝ＳＩＧ_GOV（ＳＮ，ＰＫ，Ｕ，Ｄ₁，Ｄ₂，Ｘ₃₆₅，Ｙ₁，［Ｘ₃₆₅ ¹，Ｚ₃₆₅ ¹］，...，［Ｘ₃₆₅ ^k，Ｚ₃₆₅ ^k］）
ここに、通常のように、ＳＮは証明書(cert)の一連番号、ＰＫはユーザの公開鍵、Ｕはユーザの識別子、Ｄ₁は発行日、Ｄ₂は失効日、Ｘ₃₆₅はバリディティ・フィールド、Ｙ₁は無効フィールドであり、そしてＸ₃₆₅ ^jはＣＡ^jのバリデーション・フィールド、Ｚ₃₆₅ ^jはＣＡ^jの保留フィールドである。

そのような証明書は、政府ＣＡにより省のＣＡからの入力で発生される。ユーザＵを特定し、特有の一連番号ＳＮと、発行日Ｄ₁と、失効日Ｄ₂を選択した後で、政府ＣＡはＳＮ、ＰＫ、Ｕ、Ｄ₁、Ｄ₂を（なるべく認証された形で）各省のＣＡへ送る。その後でｊ番目のそのようなＣＡが、２つの秘密２０バイト値Ｘ₀ ^jとＺ₀ ^jを選択し、（ＳＮ、ＰＫ、Ｕ、Ｄ₁、Ｄ₂、Ｘ₀ ^j、Ｚ₀ ^j）をまたはより簡単には（ＳＮ、Ｘ₀ ^j、Ｚ_0j）を局部的に保存し、［Ｘ₃₆₅ ^j，Ｚ₃₆₅ ^j］を政府証明書に包含させるために位置ｊ（または「ラベル」ｊで）に戻す。

この証明書Ｃは、省ごとに、１‐証明書(cert)、２‐証明書(cert)、...、ｋ‐証明書(cert)として、すなわち、ｋ個の独立した証明書(cert)として機能するように、本発明の分布実施で次のようにして管理される。ｎ入力装置に、１００の応答側を考える。政府ＣＡは、Ｃが依然として有効であるならば、１００の応答側の全てに２０バイト値Ｘ_365-nを送り、さもなければＹ₀を送る。その後で、ｊ番目の省のＣＡは１００の応答側の全てに２０バイト値Ｘ_365-n ^jを送って、さもなければＺ_365-n ^jを送って、Ｃをｊ‐証明書(cert)として依頼できることを示す。

したがって、政府ＣＡはユーザの特定と証明書の発行にもっぱら責任を負うが、各省のＣＡは事実上はそれ自身の証明書であるものを独立に管理できる。（これは絶対に重要である。ＣＡ¹が司法省で、ＣＡ²がＤＯＤであるとすると、利害関係がいくらか重なり合うにもかかわらず、おのおのが他方とは独立に行動することが最上である。）その結果としての証明システムは運用が非常に経済的である。まず、証明書(cert)の数が極めて減少されることである（原則として１人の被用者当りちょうど１つの証明書(cert)のことがある）。第２に、所与の被用者が、以前の証明書(cert)を無効にし、または新しいものを発行する必要なしに、１つの省を去って別の省に入ることができる。第３に、異なる省のＣＡが同じ応答者を共用できる。（実際に、所与のユーザが所与の省に所属させられているという単なる事実が秘密ではない場合には‐ほとんどの省で真実である何者かである‐サーバは「公開可能な情報」のみをほぼ含んでいる。）したがって、ｊの証明書としてのＣの状態についての質問は２つの２０バイト値、１つは政府の証明書(cert)であり、１つはｊ証明書(cert)、で応答される。これにより、（例えば、ＵがＰＫに対応する秘密鍵を紛失したとすると）「中央レベル」でＣをより迅速に無効にできるようになる。

例１０：
上の例では、証明書Ｃは中央で無効にできるのみであったが、無効にする責任を個々の省に降ろすようにすることは容易にできる。例えば、ｊ番目の省ＣＡが、完全に自律的に、Ｃを無効およびｊ証明書として保留できるようにするために、Ｃは次のような形を取ることができる、
Ｃ＝ＳＩＧ_GOV（ＳＮ，ＰＫ，Ｕ，Ｄ₁，Ｄ₂，［Ｘ_N11，Ｙ₁ ¹，Ｚ_N1 ¹］，...，［Ｘ_Nk ^k，Ｙ₁ ¹，Ｚ_Nk ^k］）。

また種々の省がそれら自身の証明書(cert)のために種々の時間確度を持つことがある。これもまた次のような形のＣを持つことにより容易に行うことができる。

Ｃ＝ＳＩＧ_GOV（ＳＮ，ＰＫ，Ｕ，Ｄ₁，Ｄ₂，［ＴＡ¹，Ｘ_N1 ¹，Ｙ₁ ¹，Ｚ_N1 ¹］，...，［ＴＡ^k，Ｘ_Nk ^k，Ｙ₁ ¹，Ｚ_Nk ^k］）
ここにＴＡ^jはｊ番目のＣＡの時間確度、Ｎ_jはＤ₁とＤ₂の間の時間単位の数である。（例えば、ＴＡ^jが１日で、Ｄ₁−Ｄ₂＝１年であるとするとＸ_Nj ^j＝Ｘ₃₆₅ ^jである。）
単一の組織内では、上記のようにして構成されて管理される証明書(cert)を発行することの大きな利点は、ユーザが１つの下部機関から別の下部機関へ移動してもその証明書(cert)がそのまま使えることができることである。しかし、上記技術は単一機関領域の外部でも応用できることを理解すべきである。確かに、政府ＣＡは持ち主ＣＡと見なすことができ、ｋ個の省ＣＡは関連しない機関（下部機関ではなくて）のために役務を行う借り手ＣＡ見ることができ、証明書をリースされた証明書(cert)と見ることができる。この用語は、「合同建設および独立管理」の利点が適用されるよりなじみのある例から借用したものである。リースされた証明書(cert)は実際に同一の床フットプリントを持つスペックビルディングに類似する。

まさに彼自身のアパートである建物ではなくても、建て主は２０床の建物をより良く建築し、彼自身はペントハウスアパートに居を構え、他のフロアは貸すか売り渡す。そうすると、２０人の各入居者は単独の所有者として行動する。彼は完全に自律して決定し、彼の階層に入居させて、鍵を渡した建て主に義務を負わない。２０階建ての建物は２０軒の平屋よりはもちろん安い。費用はそれの１０倍することもよくある。この規模による節約はリースされる証明書(cert)では一層顕著である。たしかに、定期的な証明書(cert)の発行の費用とリースされる証明書(cert)の発行の費用はほとんど同じである。したがって、リースされる証明書(cert)を発行することは貸し主ＣＡにとっては非常に利益になることがあり、または少なくともそれ自身の証明書(cert)のために要する費用を完全に取り戻す。他方、借り手ＣＡにも実際に利益があり、（それらは公開データのみを持つので）、発行経費を削減し、証明書(cert)をｋ通りのやり方で発行する費用を共同で負担し、下部構造の費用を削減し、同じ応答側を共有する。

外部の借り手ＣＡに対して貸し主ＣＡとして振る舞って当然なものは、クレジットカード会社、大規模な金融団体、および再び政府（例えば、ＵＳＰＳまたはＩＲＳを介して）である。多くの場合に、実際に、彼等は何百万もの「ユーザ」と超機関の密接な「関係」を持ち、ユーザ特定のために余り多くの資源を投資することなくデジタル証明書(cert)を容易に発行できる（例えば、クレジットカード会社はそれの顧客のために請求書を何年も送り、この知識を用いてレバレッジ取引きを行うことができる）。クレジットカード会社は、それ自身の近縁プログラム（ホテルチェーン、航空路線等を彼等のテナントとして有する）を一層効果的に実行するために証明書を貸し主ＣＡとして発行するという考えを好むことがある。ＩＲＳはデジタル証明書を使用することを既に決定していることがあり、リースされる証明書(cert)は後で、より迅速でより良いサービスを提供するために要する費用を償還する歳入を彼等に提供することができる。

例１１：
これまでは、貸し主と借り手のＣＡについて説明してきたやり方は、貸し主ＣＡが発行プロセス中はそれ自身の借り手ＣＡと協働すること、およびしたがって、前もってそれの借り手ＣＡとして既に特定していることを要する。しかし、例えば２０の借り手の全てまたはどれかを特定することなく、それらの借り手のＣＡを想定してレンタル証明書(cert)を貸し主ＣＡが発行することは実際に可能である。それよりも、将来の借り手ＣＡは既に発行されている証明書(cert)中のスペースを借りることができるであろう。この性能は新しい証明書(cert)が可能にする用途にとって理想的である。何百万という顧客に証明書(cert)を発行するために要する経費を掛けるよりも、証明書が可能にする新商品を提供する企業は、何百万もの証明書(cert)を発行した貸し主ＣＡに接近し、ファクスの後でそれらの中のスペースを貸し、その後で、貸し主ＣＡユーザの対応する証明書(cert)の全てを一晩中ターンオンすることにより貸し主ＣＡユーザの大部分を顧客として署名し（顧客特定費用やその他の発行費用なしに）、その後でそれ自身の規準に従ってそれらの管理を開始する。以下にこの機能を可能にする種々の技術について説明する。

付加システム：
装置バリデーション・システム：
ここで、本発明の技術を装置（例えば、携帯電話、ＰＤＡ、無線周波識別トークン、ＰＣ、ラップトップ、ＶＳＲ、ネットワーク装置、ルーター、ファイヤウォール、セットトップ・ボックス、ＣＤプレイヤー、ゲームプレイヤー、ＤＶＤ装置等）にどのようにして応用できるかについて説明する。

例えば、それらの装置をオンにする性能そのもの、またはそれらに動作を続行させる性能そのものについて考える。例えば装置が盗まれたとすると、それはもはや動作しないことが望ましい。他方、もし盗まなければ、それは正常な動作を続行すべきである。同様に、ユーザが装置を「借りる」とすると、または使用料を支払うか、企業のために装置を使用するものとすると（他あるいは、装置が企業のラップトップ）、もし彼が借り賃または使用料をもはや支払えないか、企業のためにもはや働けないとすると、装置をオフすなわち動作不能にする必要がある。それ以外は装置は適正に動作せねばならない。またそれらの装置はダイナミックにオン、オフおよび再びオンにできる。

もちろん、それらの機能は本発明の好適な実施形態のシステムにより実行できる。要するに、いかなる限定も意図することなく具体的にするために、毎日の時間粗さを再び仮定すると、装置は、バリディティ・フィールドＸを指定するデジタル証明書Ｃを備えることができ、装置は、Ｘに対してバリディティの毎日の証明を有するならば、所与の日に動作できる。装置は（特にセルラー装置ならば）それ自身の日常のバリディティ証明を「押す」ことができる。あるいは、装置はその日のためのそれ自身のバリディティ証明を第２のエンティティに求めることがある。例えば、装置はそれの一連番号を与え、それに応じてその日のバリディティ証明を受けることができる。

これが機能する理由は、バリディティ・フィールドが一貫していることが証明書により保障され、したがって、ＣＡのＸのデジタル署名により（日付情報などのその他の情報と一緒に）保障されるからである。しかし、Ｘの一貫性を以下のような代わりのやり方で、すなわち、変更できないやり方で装置に「それを焼き付ける」ことにより、または例えばチップ（スマート‐カード／ＰＤＡ／電話／ラップトップ等、チップセット）内の読出し専用メモリに書込むことにより守ることができる。このようにして、装置のユーザはＸをどのようにしても変更できない。証明検証アルゴリズムを焼き付けることもできる。したがって、所与の日に対するバリディティの証明Ｐであると称されているものがひとたび提示されると、Ｐは適切な回数ハッシュされ、その後で焼き付けられたＸと比較される。より一般的にいえば、ここで、一方向ハッシュ関数ではなくて、一方向関数Ｆを使用できる。したがって、製造を含めた、全プロセスはこのように見える。

第１のエンティティが最初の値を生じ、最後の値ＦＶを得るように一方向関数Ｆを所与の回数反復する。第２のエンティティ（おそらく第１のものに等しい）がＸを装置Ｄに焼き付ける。装置Ｄは関数Ｆを反復する手段を有する。装置Ｄは後で称されたｎ、ｎは正の整数、番目の証明値ＰＶを後で受け、ＰＹについて関数Ｆを反復することによりＰＶをｎ回検証し、その結果の値が焼き付けられた値Ｘに等しいことを調べる。

装置Ｄはそれの自身のクロックを参照してｎ番目の証明値が現在の日付に合致することを確認する。実際に現在の日付が、固定された日付から始まる一連の日付中のｎ番目の日付のことがある。固定された日付は装置に焼き付けることができると共に、それの一貫性も同様に守る。

反復毎に、関数Ｆは付加入力を入力として（以前に計算された値ばかりでなくも）受ける。例えば、Ｄの識別子が各反復における入力のことがある。そのような付加入力は異なる各反復毎に同様に異なることがある。例えば、整数ｋは反復ｋにおける入力のことがある。

また、単一の一方向関数Ｆがないこともある。確かに一連の一方向関数があるかもしれず、Ｆｋは反復ｋで適用される関数のことがある。

バリディティ・フィールドＸ（Ｄにとってほぼ独特である）は、Ｄの一連番号とバリディティ・フィールドを取り扱うことを別々に分けるように、Ｄの識別子（またはそれの一部）として使用することもできる。

説明しているシステムは所与の装置Ｄを全くオンまたはオフするためにこれまでは使用できる。しかし、それは所与のただ１つの関数、またはいくつかの関数の内から１つの関数をオンまたはオフにするためにも使用できる。例えば、Ｘを関数ＦＸのためのバリディティ・フィールドとし、Ｚを関数ＦＺのためのバリディティ・フィールド、等々とすることができる。この場合には、Ｘ（Ｚ）に対するバリディティ証明を受けることは、関数ＦＸ（ＦＺ）がその日に装置Ｄに対してオンにされることを意味する。そのような付加バリディティ・フィールドＺ、...は装置Ｄに焼き付けることもできる。また、どの関数がＸ／Ｚ／...に関連させられているかの記述／識別子を焼き付けることもできる。

可能な関数の数（したがって、バリディティ・フィールドの数）が大きいとすると、バリディティ・フィールドをMerkleハッシュでき、その後でMerkle木のルート値を焼き付けることができる。この場合には、関数ＦＸをオンにするために（所与の日に）、Ｘに対するバリディティの適切な証明（その日のための）を、ＸからMerkle木のルートまでの認証経路と一緒に、与えることができる。Merkle認証経路アルゴリズムも焼き付けることができる。

クロックなし装置のバリデーション：
これまで見てきたように、好適な実施形態の技術は装置を有効にするために使用でき、それらの誤使用を防ぐように装置をオンまたはオフにすることにより。この用途のセキュリティは、装置が敵、おそらく装置の本当の所有者（銃撃された後で、家に依然としてある会社のラップトップから会社のデータにアクセスすることを望む被用者）によって制御できない、という事実にしばしば依存する。実際に、会社がｊ日のバリディティの証明をもはや発行しないとしても、かつそのようなバリディティ証明が存在しないとしても、装置はｊ日には動作せず、敵は、現在日がｄ＜ｊであると装置に信じさせるように、装置のクロックを戻すことができ、その後でｄ日に正しく発行されたバリディティの証明を装置へ戻すことにより、装置をだましてｊ日に動作させる。
この好適な実施形態は、クロックなしすなわちクロックを持たないか、セキュアなクロックを持たない装置に対してさえも装置のバリデーションを行う技術を提供する。

この技術は検証者、一連の日のうちの所与の日に、所与の装置をバリデートすべきかどうか‐すなわち、オンまたはオフにする‐を判定するエンティティを考えている。具体的には、ただし意図する限定なしに、所与の日が一連の日のうちの所与の日であると仮定する。装置は、セキュアなメモリ部とクロックを持つことが好ましい。安全ではないが、装置は、少なくともオンにされている間に所与のクロックがリセットされたかどうかを示すことができる。例えば、装置は、それが動作している間に、２４時間が経過したかどうかを示すことができる。変更されることをどのようにしても避けるように、バリデーション・ソフトウエアは装置内で保護されることが好ましい（例えば、保護されているメモリ内で動作、または焼き付けられる、あるいはファームウェアに常駐する）。あるスマートカードが同様にして機能することに注意されたい。例えば、それらは保護されているメモリ部を有し、それらは記憶装置に所与の値を保持する（例えば、安全）ための最小電力を持つことができ、かつクロックを有するが、いかなるかなりな長さの時間もクロックに動作を継続させることができる電池は有しない。このように、カード読取器にひとたび挿入されると、スマートカードのクロックは動作するようになり、カードは時間の経過を安全にモニタでき（クロックも安全なメモリないにあるので）るが、カードが読取器からひとたび取り出されるとクロックはもはや機能しないが、小さな値が安全なメモリに依然として残留することがある。

例１２：
この方法では、バリデータおよび装置は秘密鍵Ｋを共用する。鍵Ｋは装置の安全メモリ部に常駐することが好ましい。この鍵Ｋから、装置とバリデータは一連の日に対応する予測できない一連の値を発生できる（Ｋを持たない第三者のために）。例えば、各日１、２、...毎に一連の値はＶ１＝Ｈ（Ｋ，１）、Ｖ２＝Ｈ（Ｋ，２）、...より成る。ここにＨは一方向ハッシュ関数、または各時刻に鍵Ｋで１，２，...を暗号化する暗号化関数である。ｊ日に、装置がもう１日多く動作することをバリデータが望んだとすると、それは値Ｖｊ＝Ｈ（Ｋ，ｊ）を知らせる（すなわち、応答側へ送る）。ここで、ｄ日に装置が動作させられ、その後でｊ日までオフにされた後で、ｊ日に装置がオンにされると仮定する。その後で、装置は値Ｖｄ＝Ｈ（Ｋ，ｄ）またはそれが動作していた最後の日のインディケータ（例えば、ｄ）を保持する。装置はｄ日の後でバリディティ証明を得るまで再び動作しない。あるいは、装置は、ｄ日の間それが動作した時間の長さを、例えば、単一の変数で、それ自身の判断で保持し続ける。したがって、装置がオフにされると、それはｄばかりでなく、例えば、６時間１０分喪記憶できる。そうすると、再びオンにされると、それは１５時間と５０分も動作を続ける。その後で、ｄの後の日についてバリディティの証明を求める。ここで、装置はｊ＞ｄ日に実際に再びオンにされると仮定する。その後で装置はｊ日にバリディティの（主張された）証明Ｖｊを得る（例えば、応答側に対する要求の後で、それはそのような証明を押し付けられ、またはその証明を受ける）。その後で装置はＶｊがメモリに現在ある証明Ｖｄの後の（またはｄの後の日にメモリにある証明に対する）バリディティの証明かどうかを調べようとする。例えば、装置は、値Ｖｊが発生されるまで（または所与の総数の日を過ぎるまで、例えば、１００００日の後は動作している装置についてもはや全く注意しないと考えることがある）それの秘密鍵Ｋを用いてＶｄ＋１、Ｖｄ＋２、...を発生し続ける。もしそうならば、それは別の２４時間それ自身でオンになり（すなわち、新しいＶｊまたはｊをメモリに保持する）、２４時間の連続オンに達した後で、新しい値Ｖｊ＋１またはＶｋ，ｋ＞ｊ、我必要とされるように、適切に動作してクロックをモニタする。

装置は、将来のバリディティ証明を知らせたりそれに供給することによりオフにでき、またはＨ（Ｋ，ＮＯ ＭＯＲＥ（これ以上はしない））などの特殊な値、またはメモリに保存されている特殊な値Ｖｎｏｍｏｒｅを知らせたり、それに受けさせたりすることにより永久にオフにできる、等。装置は、特殊な値、例えば、Ｈ（Ｋ，ｓｕｓｐｅｎｄ（保留），ｊ）を知らせたりそれに受けさせたりすることにより所与の日に停止でき、バリディティ証明、無効証明および停止証明のための鍵は、同じにすることもできれば、異ならせることもできる。

これは多くの保護を既に提供している。装置がｊ−１日に適切に使用され、その後でそれが盗まれ、ｊ日のためのバリディティの証明がいつまでも知らされないか装置に利用できなくされたと仮定する。そうすると、盗まれる前に装置がオフにされたか否にかかわらず、ｊ日に始まってそれは動作を停止する。実際に、それがオフにされたとすると、動作を開始するとｊ−１日の後の日にそれ自身を適切にオンにするためバリディティの証明を必要とせず、そのような証明は来ない。オンにされている間にそれが盗まれたとすると、せいぜい２４時間後にそれはいずれにしても動作を停止する。

最悪の場合には装置がオフにされる（例えば、ｊ−３日に）ことがたまたまあり、したがって、バリディティ証明Ｖｊ−３を所有するようになり、その後でオフにされる。この点で装置が盗まれたが、ｊ−１日までそれに気付かなかったか、装置がｊ−１日に盗まれて、敵が装置が知ることができた値Ｖｊ−１とＶｊ−２を記録するものと仮定する。その後でその敵は装置にそれら２つの値をせいぜい供給して、たかだかも２日動作させる。

例１３：
この方法は、例１１で述べた方法とほぼ同様に動作し、一連の日の各日（例えば、限定なしの日）に装置に知らせられるかその他のやり方で装置が利用できるようにされる予測できない値、安全でないクロック、等を用いるが、秘密鍵は装置に使用しない。例えば、装置は、Ｘｋ、すなわち、上記のように同じ変形で、初期値Ｘ０に対して１つの（または複数の）一方向関数Ｆをｋ回反復した結果、を保存する。その後でＸｋはファームウェアに（例えば、変更できないやり方で）書込まれ、またはメモリの保護されている部分に保存される。ｊ日におけるバリディティの証明は、本発明の基本形におけるように、単にＸｋ−ｊである。再び、停止および無効が類似のやり方で起こり得る。

ＲＴＣ物理アクセス構成：
雑多な環境における多数の特権管理：
頑丈な（ロバストな）アクセス管理システムはあらゆるユーザに対して２つの質問に答えねばならない。第１の質問は認証または特定についてであて、「あなたはあなたが自分がそうであるとおっしゃっている方ですか」。この質問は通常は直接に、または識別バッジ、バイオメトリックス鍵、またはパスコードを介して間接に行われる。それらは長く継続するユーザ特定のために妥当な解答を与えるが、「あなたが試みようとなさっていることをあなたは現在許されていますか」というより時間的に重要なバリデーション質問は向けない。

例えば、識別バッジはＡｌｉｃｅが過去１０日間のある期間被用者として雇用されていたことは示すことはできるが、彼女がコンピュータサービス室に入る許可を与えられている被用者のままであるかどうかを独立に決定できない。

物理アクセス管理のために、安全な錠は認証によって同一性を判断し、その後でユーザの現在の特権が入場を許しているかどうかを判断するためにバリデーションを行わねばならない。ある種の錠はこのバリデーションを中央が信託している許可権限期間への有線ネットワーク接続を通じて実行する。有線ネットワークで接続されている錠には２つの大きな限界がある。各有線接続錠の費用には配線を安全に保持する費用と、フィールド管理パネルの費用と、労賃を含んで、総額でドア当り数千ドルに達する。有線接続構成の範囲は、常時ネットワーキングにより容易にアクセスできる錠ま手に限られる。これは、車両、保管コンテナ、万能キャビネット等などの移動体、または錠に達することが困難なものに強固なアクセス管理を使用することを妨げる。

本発明の好適な実施形態のリアルタイム証明書技術は、接続されている錠または切り離されている錠の双方に効率的なバリデーションを行うために安全なやり方を提供するものである。これにより知能ドア錠が、各錠への費用のかさむネットワーク接続を要することなく、現在のユーザ特権をバリデートし、許可を与えることができるようにされる。

この開示は、多数の独立したユーザ特権を基にして、切り離されたバリデーションを行うために使用できるいくつかの構成を示すものである。各構成は、異なる施設で使用するための既存のアクセス管理ハードウェアおよびソフトウエアと組合わせて、相互に動作できるようになっている。各構成ごとに、この明細書はリアルタイム証明書技術がどのようにして融通性を高め、しかも高い安全性を達成するための費用を劇的に低減できるかを説明するものである。

以下に説明する全部で４つの構成は同一のＲＴＣバリデーション・プロセスを特徴とするものである。それらの構成の間の主な違いはユーザを認証する過程であって、それは費用を大幅に低減し、かつ既存のアクセス管理解決技術に適合することである。

非接触ＩＤ／メモリ：
最初のＲＴＣバリデーション構成は、読出し／書込みメモリアクセスを行う非接触ＩＤカードを基にしたアクセス管理環境である。これを例として共通ＭＩＦＡＲＥＴＭ規格非接触カードを用いて説明するが、バリデーション解決技術はどのようなメモリＩＤカードとも同じである。

現在のネットワークで結ばれている物理アクセス環境にＭＩＦＡＲＥＩＤカードが使用される場合は、錠はカードからＩＤを読取り、それを近くのパネルまたはサーバへ送る。パネルまたはサーバは特権を調べてバリデーションを行う。認証過程はカードＩＤの判定であり、バリデーション過程はこのＩＤを基にして遠隔で取り扱われる。

本発明の物理アクセス管理は有線接続されているドアのためのこのモデルとの適合性を維持するが、その角の矯めのデジタル署名されている「バリデーション証明」を保存するためにカードの読出し／書込みメモリを使用することにより、切り離されているドアのための支援を付加する。この証明はネットワークに組み込まれている任意の読取器でカードに定期的に書込まれ、その後で、切り離されている任意のドアの所で読出してユーザの現在のバリディティおよび許可を行うことができる。

下記の表は、カードに記録されているＲＴＣバリデーション証明の論理的内容を、各構成要素に対する保存要求のあらましと共に示すものである。

カードＩＤ： ＃１２３４５６ ４バイト
状態： カードバリッド １バイト
開始時刻： ０３年８月４日午前９時 ４バイト
終了時刻： ０４年８月５道午前８時５９分 ４バイト
権限機関： ＡＣＭＥ Ｉｎｃ． ２０バイト
特権： Ｒ＆Ｄ ｌａｂｓ １〜１０バイト
駐車 １〜１０バイト
ロッカー５３ １〜１０バイト
端末装置Ｂ １〜１０バイト
デジタル署名 ４２バイト
総サイズ：約１００バイト

結ばれているドアを通ってユーザが施設に入ると、ドアは上記フォーマットでのユーザの完全なバリデーション証明を検索し、それをカードのメモリ領域に置く。証明がカードにひとたびロードされると、切り離されている錠は下記のステップによりユーザの許可を有効にできる。

（１） ユーザのカードＩＤを検索することにより標準認証を実行する、
（２） メモリからＲＴＣバリデーション証明を検索する、
（３） 信託されている権限機関の既知の公開鍵とデジタル署名が合致するか検証する、
（４） 証明が現在のものであることを検証する（開始時刻と終了時刻を用いて）
（５） カードが有効であることを検証する、
（６） 証明からの特権を基にして随意のアクセス管理要求を点検する。

切り離されている錠は、ここのユーザＩＤではなくて、特権に基づいた１組のアクセス管理規則で構成される。例えば、「駐車」特権を持つユーザのみを、執務時間中のみ入場させるように錠を構成できる。個々のユーザ特権はＲＴＣバリデーション証明を通じて変更できるので、新しいユーザが付加されたり、除かれたりする場合にアクセス許可を変更するために錠自体を変更する必要はない。また、錠はいかなる秘密鍵またはデータも保存する必要はない。その理由は個々の錠をシステム全体の安全を低下することなくばらばらにできることを意味する。

本発明の好適な実施形態のＲＴＣバリデーション証明は、物理アクセス管理環境のためにそれらの証明を独自に強力なものにするある特徴を有する。証明はデジタル署名されるので、それらは偽造できず、手を加えることができない。証明にはいかなる秘密鍵も含まれていないので、それらは公開でき、安全を損なう危険な示すように伝送できる。証明は低位終端メモリカードに記録するのに十分小さい。

それらの特徴によってＲＴＣバリデーション証明をＭＩＦＡＲＥ規格野用にカードに使用でき、しかもカード当り何千の独立したユーザ特を持つ高いセキュリティの暗号化バリデーションを提供する。

費用：ＭＩＦＡＲＥ １ｋ規格カードは製作者および製作数に応じて１ドルと５ドルの間で利用できる。ＭＩＦＡＲＥカードとＲＴＣバリデーション技術を基にした切り離されている錠はドア当り５００ドル以下である。施設により、単一のドアまたはコンテナを１０００ドル以下で安全にできる。

セキュリティ：簡単なＩＤ認証は複製や偽造に対する防護が弱い。認証のセキュリティを高めるためにＰＫＩ防護に組合わされた第２および第３の要因認証を使用できる。証明書のバリデーションは、許可の偽造または変更を阻止する強力なＰＫＩ暗号化によって守られる。

非接触共用秘密：
ＲＴＣ証明書バリデーションは、全ての読取器と直接または間接に共用される秘密情報を用いてバリデーションを実行する、ＨＩＤのｉクラスなどの識別カードに使用することもできる。クロックは、無作為にされている呼び掛け／応答プロトコルを使用しているカードであって、そのプロトコルがそれのＩＤに一致する秘密を知っていることを示すようなカードに対する認証を行う。

秘密共用カードに対するＲＣＴバリデーションは簡単なＩＤカードに対するバリデーションと同じである。ユーザが有線で結ばれているドアに入ると、錠は現在のＲＴＣバリデーション証明をユーザのカードに書込む。この証明はオフライン・バリデーションのために切り離されている読取器によって後で検索される。

費用。メモリを持つ非接触共用秘密カードは製作者および製作数に応じて５ドルと１０ドルの間で利用できる。ＭＩＦＡＲＥカードとＲＴＣバリデーション技術を基にした切り離されたドアはドア当り５００ドル以下である。施設により、単一のドアまたはコンテナを１０００ドル以下で安全にできる。

セキュリティ。共用されている秘密の認証は個々のカードの複製の機会を減少するが、単一のオフライン読取器を使用することを妥協すると多数のカードを複製されるかもしれない。証明書バリデーションは強力なＰＫＩ暗号化によって防護されて、許可の偽造または変更を阻止する。

非接触ＰＫＩ：
公開鍵デジタル署名を実行できるカードは認証セキュリティを最高度にする。これはＭＩＥＡＲＥ ＰＲＯ Ｘチップと多数の最高位ＪａｖａＣａｒｄｓを基にしたカードを含む。錠は、それにいかなる感知可能な情報も要することなく問い掛け／応答プロトコルを基にしたカードを認証することができる。これは鍵の複製のおそれを大きく減少する。

公開鍵カードに対するＲＴＣバリデーションは、簡単なＩＤカードに対するバリデーションと同じである。ユーザが有線で結ばれているドアに入ると、錠は現在のＲＴＣバリデーション証明をユーザのカードに書込む。この証明は後でオフライン・バリデーションのために切り離されている読取器によって検索される。

カードの公開鍵はデジタル証明書によって通常表される。それはコンピュータアクセスおよびｅメールのセキュリティなどの別の用途に使用できる。最高位公開鍵カードは、情報セキュリティまたは保存されている値などの付加用途を支持することがあり、それは各用途に要する総費用の低減を支援する。

費用：非接触ＰＫＩカードは製作者および製作数に応じて１０ドルと２０ドルの間で利用できる。ＭＩＦＡＲＥカードとＲＴＣバリデーション技術を基にした切り離された錠はドア当り５００ドル以下である。施設により、単一のドアまたはコンテナを１０００ドル以下で安全にできる。

セキュリティ：ＰＫＩカードは鍵の妥協またはカード複製の危険が小さくて錠に強力な暗号化認証を行うことができる。証明書バリデーションは強力なＰＫＩ暗号化によって防護されて、許可の偽造または変更を阻止する。

ハッシュ・シーケンスをトラバースする技術：
Ｈを一方向ハッシュ関数とする。長さがｎのハッシュ・チェーンは値
Ｈ(ｘ_i)＝ｘ_i-1であるようなｘ₀，ｘ₁，...，ｘ_n の集まりである。ｘ_i-1はｘ_iから計算することが容易であるが、逆向きの計算は、Ｈの一方向性のために、実行できない。

下記はハッシュ・チェーンの表現である
ｘ₀ (Ｈ)ｘ₁ (Ｈ)... (Ｈ)ｘ_n-1 (Ｈ)ｘ_n
多くの用途（例えば、ドキュメント・バリデーションおよび特権管理サービスなど）ではハッシュ・チェーンを考察できる、すなわち、値ｘ₀，ｘ₁，...，ｘ_nを順に（上の例では左から右へ）ある時間にわたって発生する（例えば、１年の間１日に１つの値）必要がある。左から右への順序はこの問題を困難にする。その理由はＨの一方向性のためである。Ｈを単に繰り返し適用することによってｘ₀，ｘ₁，...，ｘ_nを順に発生および出力することは容易であるが、逆の順序はより長い時間とより多数のメモリとの少なくとも一方を要することに注目されたい。

２つの明らかな取組み方は、
ただ１つの値ｘｎを保存し、ｘ_iを出力するために、Ｈ^n-1(ｘ_n)を計算する：
全ての値ｘ₀，ｘ₁，...，ｘ_nを保存し、それらが出力されるにつれてそれらを消去する：
第１の取組みは２つのハッシュ値（１つはｘ_nに対するもの、他方はｘ_iの計算に対するもの）と、Ｈ合計のｎ（ｎ＋１）／２回の計算、または、平均して、値出力当りｎ／２回の評価を保存することを要する。第２の取組みはｎ＋１ハッシュ値とＨ合計のｎ回の評価、または、平均して、値出力当り１回の評価の保存を要する。

我々は、中間解決法、すなわち、メモリ（保存されているハッシュ値の数）と時間（必要とされるＨの評価の回数）との別の相反する特性を提供するもの、に興味がある。

次のような相反する結果をもたらすアルゴリズムが先行技術で提案されている。すなわち、保存されている

ハッシュ値とハッシュ値出力当りのたかだか

のＨの計算である。（Don CoppersmithおよびMaruks Jakobsson、"Almost Optimal Hash Sequence Traversal（ほぼ最適なハッシュ・シーケンス・トラバーサル）"，in Matt Blaze, editor, Financial Cryptography： Sixth International Conference (FC' 02), Southampton, Bermuda, 11‐14, March 2002参照）。

一定(constant)記憶装置を有する新規なアルゴリズム：
Ｊａｋｏｂｓｓｏｎの方法は約ｌｏｇ₂ ｎ個のハッシュ値の記憶を要し、それより小さい記憶装置を使用する場合は使用できない。長さが３６５のハッシュチェーンに対しては、これは９個の値を保存する必要があることを意味し、長さが１００００００のハッシュチェーンに対しては、これは２０個の値を保存する必要があることを意味することに注目されたい。我々はそれより小さい記憶装置要求を持つアルゴリズムを使用したい。さらに、我々はハッシュチェーンの長さとは独立である記憶装置要求を指定できるようにしたい。こうすると、短いチェーンと長いチェーンに対して同じ容量のメモリを必要とし、したがって、ハッシュチェーンの長さが変化しても新しいメモリを獲得する必要はない。

アルゴリズムについての考察を便利にするために、値ｘ_jのことをアルゴリズムが位置ｊにペブル(pebble)を保存すると呼ぶ。その後でペブルは次のことを許される。すなわち、（ｉ）他のペブルが配置されている位置へ動かすこと（これは値をコピーすることに相当する）、または（ｉｉ）それの現在の位置から１段左へ動かすこと（これはＨを評価することに相当する）。最初に、ペブルはハッシュチェーンの任意の位置でスタートできる。

ペブルの数は保存されているハッシュの数に対応し、ペブルが左へ動く段の数はＨの評価の数に相当することに注意されたい。そうすると、我々のゴールは、特定のペブル数が与えられたらペブルの動く数（我々が「費用」と呼ぶもの）を減少するアルゴリズムに追い付くことである。

２つのペブル：
ｎでペブルを常に必要とすることは明らかである‐‐ｘ_nが保存されないとすると、それを取り戻す方法はなく、したがって、トラバースの終りに必要とされる時に、それを出力する方法はないことが明らかである。ｘ_iを出力できるようにするために、現在の位置ｉでペブルを常に必要とすることも明らかである。

ただ２つのペブルが使用されるならば、それのうちの１つはｘ_nに常に留まらなければならず、他方は毎時ｘ_nでスタートし、ｘ_iへ動く以外は選択できないが。したがって、２つのペブルのための最良のアルゴリズムは全部でｎ（ｎ＋１）／２回のステップ、または平均してステップ当りｎ／２ステップを取る。例えば、長さが１００００００のハッシュチェーンでは、平均ステップ数は値出力当り５０００００である。

３つのペブル：
絶対に必要な２つのペブルにちょうど１つのペブルを加えるものとすると、ステップの数を劇的に改善できることが分かる。

これは次のように行う。ハッシュチェーンを長さｓの間隔に分割する。ここに

（ｎ／ｓ ｓｑｒｔ｛ｎ｝間隔があることに注目されたい）。ペブル数３をｘ_nに置き、ペブル数２をｘ_sに置く。その後で、上で述べた２ペブルのためのアルゴリズムを用いて、点ｘ₀，...，ｘ_sをトラバースする（毎時ｘ_sでスタートする）。その後でペブル数２をｘ_2sに置き（ｘ_nでスタートして左へ動く）、２ペブルのためのアルゴリズムを用いて、点ｘ_s+1，...，ｘ_2sをトラバースする。これを続けて、そのたびに長さｓの間隔に対して２ペブル・アルゴリズムを用いる。

このアルゴリズムのステップの総数は次のようにして計算できる。２つのペブルを用いて各間隔をトラバースするために、ｓ（ｓ＋１）／２ステップを必要とする。また、各間隔をトラバースする前にペブル数２をそれの初めまで動かすために、（ｎ−１）＋（ｎ−２ｓ）＋...＋ｓ＋０ （ｎ／ｓ）（ｎ／２）ステップを必要とする。

であることを思い起こすと、出力値当りの平均ステップ数は

したがって、第３のペブルを２つのうちの小さい方に加えることにより、出力値当りの時間をｎ／２からｓｑｒｔ｛ｎ｝まで短縮できる。この短縮はまったく劇的であり、例えば、長さが１００００００のハッシュチェーンの場合には、平均ステップ数は値出力当り１０００である（２ペブルの場合に必要な５０００００とは異なって）。

４ペブル：
さらに別のペブルを利用できるとすると、ハッシュチェーンを間隔に再び分割できる。この時は、

をセットし、チェーン全体をｎ／ｓ ｎ^(1/3)に分割する。

その後でペブル数４をｎに置き、ペブル数３のためのスタート点としてそれを使用する。それはサイズｓの各間隔の開始点へ、左から右への順に、動く。各間隔で、上記３ペブル・トラバース・アルゴリズムを使用する。すなわち、各間隔をサイズ

のサブ間隔にさらに細分し、ペブル数２を、左から右への順に、各サブ間隔の初めに置く（ペブル数２はスタートし、各場合に、およびペブル数３）。その後でペブル数１はサブ間隔をトラバースし、そのたびにペブル数２でスタートする。

このように、各間隔をトラバースする費用は値出力当りｓｑｒｔ｛ｓ｝、または

である。そのために、ペブル数３を各間隔の初めへ動かす費用を加算せねばならない。ペブル数３は、最初はｎ−ｓステップ、次はｎ−２ｓステップ等というようにｎ／ｓ回動かされて、値出力当り（ｎ／ｓ）／２ ｎ^(1/3)／２の平均費用を与える。

したがって、値出力当りの平均ステップ数は

である。長さ１００００００のチェーンの例を再び用いて、平均ステップ数は値出力当り１５０である。

より多くのペブルへの一般化：
上記の例から出る一般技術は次の通りである。ｃ個のペブルが与えられると、ハッシュチェーンをおのおの長さｎ^{((c-2)/(c-1))}のｎ^(1/(c-1))間隔に分割する。それらの各間隔にｃ−１ペブルの技術を使用する。出力値当りの平均費用は（（ｃ−１）／２）ｎ^(1/(c-1))｝である。

この一般化は一定数のペブルに対するためのものばかりでなく、例えば、ｃ＝１＋ｌｏｇ₂ ｎに対するものであると考えることができる。その場合には、式

を用いて、出力値当りの平均費用が我々のアルゴリズムを用いてｌｏｇ₂ ｎであると計算する。

最悪の場合の費用の低減：
上の技術は出力値当りの平均の場合費用を低減するが、ある出力値は他のものよりも計算に長くかかる。

例えば、３ペブルの場合を取ることにする。ｓペブルをトラバースするたびに、ペブル数２を再配置せねばならない。そうすると、間隔の左端部にある出力値は計算にはるかに長くかかる。例えば、ｘ_s+1を計算するために、ｎ−（ｓ＋１）ステップを行う必要がある。他方、ある間隔内の他の全てのペブルはたかだかｓステップを取る。

これはあるようとには多くの重大な問題をひき起こすことがもちろんある。すなわち、含まれている計算機器はそれらの「悪い」場合を取り扱うのに十分速くなければならない。しかし既にその様に速いとすると、良い「平均」ケースに達する点はないようである。我々は強力な計算機器を依然として必要とし、それは平均に安住しているだけである。

この問題を阻止するために、最悪の場合の出力値の費用を平均の場合の出力値の費用に近付ける必要がある。３ペブルの場合には、これはただ１つの余分のペブルを付加することにより行うことができる。そのペブル「２ａ」を呼び出す。それの仕事はペブル２を次に動かさねばならない位置へ前もって動くことである。例えば、ペブル２が点ｓに配置されているとすると、ペブル２ａは点ｎでスタートして点２ｓへ向かって動く。それは、ペブル２がそこにある必要があるちょうどその時に、すなわち、値ｓが出力される時までに、点２ｓに達する。

したがって、サイズｓの任意に与えられた間隔がトラバースされている間に、ペブル２ａは位置ｎでスタートし、次の間隔の初めまで左へ動く。ペブル２ａはそれの宛先に達するためにｎステップより少ないステップを要することに注目されたい。明らかな取組かたはペブル２ａの場合には間隔中の各出力値についてたかだかｎ／ｓステップを要する。この結果として最悪の場合の費用は出力値当り

ステップとなる。しかし、より良くできることに注意されたい。ペブル１は、間隔の左端部における値に対しては、間隔の右端部にある値よりも多くのステップを必要とするので、最悪の場合の費用を低減するために、ペブル２は「徐々に」スタートしその後で「速く」しなければならない。こうして、ペブル１と２ａが取るステップの総数は一定のままである。特に、ペブル２ａは最初に（ｎ／ｓ）／２ステップを取らねばならず、次には（ｎ／ｓ）／２＋１ステップを取り、等々、間隔の最後の値が出力である時の３（ｎ／ｓ）／２ステップまでらねばならない、これは最悪の場合の費用を

まで低減する。

ステップの総数、したがって、出力値当りの平均費用は、この余分のペブルを付加するとともに増大しないことに注意されたい。その理由は余分のペブルが余分の仕事をせず、っそれよりも仕事を僅かに先に行うからである。したがって、長さが１００００００のハッシュチェーンでは、最悪の場合の費用は１５００であり、平均の場合の費用は出力値当り１０００である。

このやり方はより多くのペブルに拡張される。４ペブルでの解決を取ったとして、ペブル２と３のそれぞれの適切な位置に前もって動くペブル２ａと３ａを加えると、最悪の場合の費用は

まで減少する。長さが１００００００のチェーンの例を再び取ると費用は２００であり、一方平均費用は出力値当り１５０である。

したがって、一般に、２ｃ−２ペブルでは、（（ｃ−１）・２）ｎ^[1/(c-1)]の平均費用で、かつ任意に与えられた出力値に対しては（ｃ／２）ｎ^[1/(c-1)]の最悪の場合費用で、ハッシュチェーンをトラバースできる。

また、この一般化は一定数のペブルに対してばかりでなく、例えば、ｃ＝１＋ｌｏｇ₂ ｎに対しても考察できる。この場合には、２ｌｏｇ₂ ｎのペブルを用いて、我々のアルゴリズムはｌｏｇ₂ ｎの平均費用、および１＋ｌｏｇ₂ ｎの最悪の場合の費用で、ハッシュチェーンをトラバースする。

最適な解決：
以下に、任意の数ｃが与えれた場合に、おそらく最適な総（そして出力値当りの平均）計算費用を持つアルゴリズムを得る方法について説明する。しかし、ｃの小さい値に対しては、このおそらく最適な解決は、上記解決と比較してステップの数を僅かだけ減少することに注意されたい。

ｃ個のペブルを持っているとする。ｘ_nを保存せねばならず、それは１ペブルを占める。その後で、ｘ_nに対してＨをｎ−ｋ回施すことにより、もう１つのペブルがｘ_kへ動かされる（あるｋについては下で決定する）。その後で、ｘ₀，ｘ₁，...，ｘ_kを順に出力するためにｃ−１のペブルについて最適な解決法を繰り返し使用する。これはより短いチェーン、長さｋのもの、をトラバースすることになることに注意されたい。その理由は値ｘ_kが保存されているからである。こうすると最初のｋ個の値が既にトラバースされているので、より短いチェーン、長さｎ−ｋのもの、をトラバースすることに再びなる。

ここでＦ（０，ｎ）を、所与の任意の時刻にｃより多くないペブルを保存しているあいだに、長さがｎのハッシュチェーンをトラバースすために必要なステップの数と定義する。明らかに、いかなるｃ≧１に対してもＦ（０，ｎ）＝０、いかなるｎに対してもＦ（０，ｎ）＝ である。そうすると、我々の上の方法では、Ｆ（ｋ，ｎ）＝ｍｉｎ_kＦ（ｃ−１，ｋ）＋Ｆ（ｃ，ｎ−ｋ−１）＋ｎ−ｋでｋはＦ（ｃ，ｎ）を最小にするために選択せねばならない。

特定のｃとｎについて最適点ｋを見出すために再最小化での簡単な繰り返し事である（またの名をダイナミック・プログラミングともいう）。このタスクを行うＣコードを我々は提供する。そのような最適点は前もって容易に見出すことができ、その後でハッシュトラバース・コードに統合される。

任意のメモリ量に対する最適な解決法の我々の実現：

専用鍵安全物理アクセス（ケルベロス(KERBEROS)状設定におけるリアルタイム証明書）：
一般に、このシナリオは多数のドアと多数のユーザを含むことがある。さらに、アクセスは多数の権限者により管理できることがある（各権限者はいくつかのドアのアクセスを管理し、種々の権限者に対するドアセットはおそらく重なり合う）。最も一般的なレベルでは、アクセスはユーザがドアに証明書を提示することにより管理される（そのような証明書の検証は、ＰＩＮなどの、ユーザとドアの間の対話と、ドアとユーザらどの間のメッセージ交換を要求することがある）。ドアの場合には、最低の費用で、かつドアをネットワークまたはいかなる特定のサーバへも接続することなく、アクセスのセキュリティを支えることが特に重要である。

１つの重要な観察は、使用する証明書がどのようなものであっても、我々のＲＴＣ技術により重要なセキュリティの利益、下部構造の利益および費用の利益を得ることができる。ＲＴＣは公開鍵暗号化法（証明書、公開鍵署名、ＰＫＩ）および専用鍵暗号化ツール（対称的または専用鍵署名および暗号化、ケルベロス‐類似システム、等）と共に利用できる。

公開鍵技術を使用する切り離されて領域ドアのアクセス管理が求められてきた。ここでは専用鍵技術にそれらの技術をどのように適用するかについて説明する。

基本原理：
暗号化、署名、疑似ランダム関数：
特に、専用鍵暗号化、専用鍵署名（またの名をＭＡＣともいう），専用鍵ランダム関数は我々が使用するであろう典型的な専用鍵原理である。我々の目的の多くでは、それらの原理は互換的に使用できる。例えば、決定論敵専用鍵技術（秘密署名鍵ＳＫを共用している２つのエンティティの間の）と、ランダム関数Ｆｓ（それの種ｓが２つのエンティティの間で共用される）は同等であると実際に考えられる。両方とも、対応する入力を知るかもしれないが、ＳＫやｓは知らない、第三者が予測できない出力を生ずる。例えば、秘密鍵ＳＫを有するｘのデジタル署名を戻す関数ＦＳＫ（ｘ）は、実際に、種ＳＫを持つ十分に良い疑似ランダム関数であると考えることができる。他方、入力ｘで種がｓである疑似ランダム関数Ｆのｘに値を戻す関数Ｆｓ（ｘ）は、秘密鍵ｓを持つ専用鍵署名アルゴリズムと考えることができる。

一方向および一方向ハッシュ関数：
我々は別の基本原理も使用する。それは一方向関数Ｆおよび一方向ハッシュ関数Ｈである。要するに、関数Ｆは、（１）入力Ｘが与えられると、Ｆ（Ｘ）を効率的に計算でき、（２）Ｆ（Ｘ）、十分に予測できないようにＸは十分無作為に選択されていることが好ましい、が与えられると、Ｘを計算することは実際には不可能である（例えば、Ｘに対してあまりに多すぎる値は原則として試行統べきであり、可能な候補の数を少なくする効率的な方法は存しない）。関数Ｈはそれが一方向であるならば一方向ハッシュ関数であり（もっとも、より長い入力をより短い入力にマッピングすること、または任意に長い入力を‐例えば、１６０ビット入力、にマッピングすることが好ましい）、Ｈ（Ｘ）＝Ｈ（Ｙ）であるような２つの異なる入力ＸとＹを見付けることは困難である。

実際に、他の原理を構築するために我々は一方向ハッシュ関数Ｈを使用できる。例えば、専用鍵署名を下記のような簡単なやり方で構成できる。メッセージＭを秘密鍵ＳＫで署名するために、Ｈ（ＳＫ，Ｍ）を計算する、すなわち、ＳＫとＭを適切に組合わせ−例えば、それらを連結する−その後で結果をハッシュする。もちろん、署名して日付Ｍを記入するために、日ｄをこの組合わせに付加して代わりにＨ（ＳＫ，Ｍ，ｄ）を計算する、同様に、疑似ランダム関数を次のようにして構成できる。ｘを入力して種がｓの疑似ランダム関数Ｆの出力を生じ、Ｈ（ｓ，ｘ）を計算できる。すなわち、ｓとｘを適切に組合わせ、その後でその結果に一方向ハッシュ関数を適用する。

セキュアな物理アクセス：
我々は専用鍵設定によって導入された新規な面そのものに的を絞り、新たなシナリオに当然適用できるそれらの共通の面（例えば、毎日の／定期的な計算の面等）は飛ばす。

単一の機構：
Ｄをドア（前記メカニズムを持つ）とし、ＡをＤへのアクセスを管理することを望む機関、Ｕをユーザ（おそらくＡのために働いている）とする。そのユーザは適切な識別子、等が記録されているカード、ＣＵ、を再び持つ。そうするとＡは秘密鍵ＳＫをＤと共有することによりＤに対するアクセスを管理できる。Ａがｄ日（時間間隔ｄ）にＵがＤにアクセスすることを許可したいと望むと、それは証明ＰＵＤｄを計算する。Ａ以外の誰も（およびおそらくＤ）にとっても計算することは困難であるが、Ｄにとっては検証することは容易である。専用鍵暗号化および専用鍵署名を用いてこれをどのようにして行うことができるかを見ることにする。

専用鍵暗号化解決策（身元の可能な限りの証明で）：
例えば、ＤＥＳなどのある設定されている専用鍵暗号化アルゴリズムに従って専用暗号化鍵ＳＫで、ＰＵＤｄをＵおよびｄを、Ｄもおそらく同様、指定するメッセージの暗号化、ＥＵＤｄ、にできる。ＵのカードからＥＵＤｄを受けると、Ｄは鍵ＳＫでそれを解読し、その結果がＵと現在の日（時間間隔）ｄを指定するものならば、ドアは開く。ドアはそれ自身の時間が時間間隔ｄに入っているかどうかを判定するためにそれ自身のクロックを使用できる。

ここで、他の場合と同様に、ＵはユーザとＵの適切な識別子を示すことを意図されている。ユーザＵが彼に関連するカードを（なるべく安全に）所有しているならば、Ｕはそのようなカードまたはそれの適切な識別子とすることができる。後者の場合には、例えば、ドアのカード読取器はカードからＵを得ることができ、またＥＵＤｄも得ることができ、その後で鍵ＳＫでＥＵＤｄを解読して解読されたＵをカードにより提供された反れと比較して、それらが同一であることを確かめる。

ＥＵＤｄはユーザＵが時間間隔ｄでドアを通ることを許可されていることをドアＤに証明するが、これはそれがユーザＵを確かに相手にしていることはＤに証明するものではないことに注目されたい。このように、Ｕが彼が間違いなく彼である事をドアに証明するやり方でこの基本技術を向上できる。これは各種のやり方で実行できる。特に、権限機関ＡはＥＵＤｄをＵのカードにのみ提供でき、Ｕのカードにはキーパッドが設けられ、正しいＰＩＮがそれのキーパッドに入力された場合にのみＥＵＤｄをドアＤへ転送できる（そして、誤ったＰＩＮが所与の回数以上入力されたならば、カードは自己破壊でき、またはそれの関連する揮発メモリ内容を消去する）。このようにして、ドアがＥＵＤｄを受けると、ドアはＵのカードから受けていることを知り（ＡはＲＵＤｄをＵのカードへ転送するのみであるので）、かつ、ＵのＰＩＮがそれのキーパッドで入力されていなければＵのカードは機能しないか、ＥＵＤｄをＤへ転送しないので、「カードの背後のユーザ」がＵに間違いないことを知る（盗んだＵのカードを持つ悪意のユーザではなくて）。Ｕが彼が本人であることをＤに証明する第２のやり方は、Ｕが彼自身のＰＩＮをＤに直接提供することより成る。例えば、ドアＤにはそれ自信のキーパッドを設けることができ、Ｕはそれを使用して彼自身のＰＩＮ、ＰＩＮｕを入力する。ドアはＰＩＮｕをＵにマップする内部的な手段（例えば、表）を持つことがあり、したがって、ドアがたしかにＵを相手にしていることを理解できる。しかし、システムに多数のドアがあるならば、各ドアに表を提供したり、その表を更新する（例えば、新たなユーザがシステムに加わるために）ことは実際的でないことがある。したがって、Ｕの識別子を直接にＰＩＮｕとすることが好ましいことがある。例えば、ＥＵＤｄがＥＰＩＮｕＤｄのこともある。ユーザＵがドアに接近すると、彼はＰＩＮｕをＤのキーパッドに入力し、彼のカードがＥＰＩＮｕＤｄをドアへ転送する。その後でドアは入力されたＰＩＮがＥＰＩＮｕＤｄで指定されているものに等しいかどうかを調べこの場合には正しいユーザを相手にしており、この同じユーザは何等かのＰＩＮ‐ユーザ表を使用することなくドアＤを通ることをＡにより許可される。たしかに、キーパッドはＰＩＮｕを知っているユーザがＤの前にいることをそれに知らせ、ＥＰＩＮｕＤｄはＰＩＮｕを知っているユーザがＤを通ることを現在許可されていることをそれに知らせる。第３のやり方では、ＥＵＤｄに直接現れるよりも、ユーザＰＩＮをＥＵＤｄに安全に結合できる。例えば、ＡはＥＵＤｄを、ＰＩＮｕから再構成できる（例えば、ｋ＝Ｈ（ＰＩＮｕ）またはＫ＝（ＰＩＮｕ，ｄ）あるいはＫ＝（Ｄ，ＰＩＮｕ，ｄ）等）鍵ＰＩＮｕまたは鍵Ｋで暗号化されているＵのカードに与えることができる。この場合には、ドアＤはＰＩＮが時間間隔ｄに対するユーザの許可に安全に結び付けられていることを調べる。例えば、それはＥＵＤｄを解読するためにＰＩＮｕを使用し、ＥＵＤｄが適切な許可であることを、それが権限機関Ａと共用している鍵ＳＫを用いて調べる。

応答側(responder)を使用する：
しかし、ＡはＥＵＤｄをＵのカードへどのようにして容易かつ安全に転送できるのであろうか。おれらは装置（サーバ端末またはコンピュータ端末／サーバにリンクできるカード読取器）である。それらの応答側は金庫したり保護したりする必要はない。そのような保護はシステムに多額の費用を負わせたり、非常に不便であるので、応答側を安全にすること無くシステムが安全に動作できるようにすることが重要である。理想的には、権限機関Ａが一連の日のうちの毎日ｄに更新を行う。各日は時間間隔（例えば、日）を指定することが好ましい。例えば、ｄは日ｄまたは日ｄの始まりとすることができる。ｄの更新中は、ＡはどのユーザＵにドアＤにアクセスする／ドアを通る許可を与えるかを判定し、この事実をＤにより検証できる証明を計算する。例えば、暗号化を基にした共用鍵システムでは、この証明は上記列ＥＵＤｄとすっることができ、ＡがＥＵＤｄを計算するために使用した鍵ＳＫをＡがＤと共用するので、検証できる。その後でそれらの証明の全ては応答側へ送られる。それらの応答側は都合の良い場所に配置することが好ましい。例えば、空港のシステムでは、応答側は空港の主出入り口に配置できる。その後で（例えば、作業に着いた時）ユーザＵはドアＤを通る彼自身の許可を応答側から取り出す。ＥＵＤｄを受けるためにＵのカードはそれ自身を応答側に対して認証できることが好ましい。これは非常に便利である。その理由は無線その他の費用のかかるシステムがないので、ユーザは、所与の日に彼が通る資格を与えられている全てのドアについての彼の毎日の許可を正面入口（それを通って彼がともかく入る）から得て、彼自身のカードをカード読取器に挿入することに似た従来の機構を使用する（彼が仕事のために現れたことを証明するため）。その後では、彼は空港の周囲を自由に歩き回ることができ、彼が通る資格を与えれている全ての保護されているドアＤを、彼が得た許可ＥＵＤｄを用いて容易に通ることができる。しかし、このように便利名個とと、応答側が安全でないことが好ましいという事実のために、悪意を持つユーザも正直なユーザの許可を得ることがある。したがって、（１）応答側を安全にすることなしにこれが起きることを阻止することと、（２）正直なユーザに対する許可を他の誰もが使用できないようにすること、のうちの少なくとも一方を置こう会うことが必要である。後者の場合には、すでに述べたように、ユーザがＰＩＮをドアにも入れることにより十分に強制できる。これはカードにより出された許可に確実に結び付けることが好ましい。このようにして、Ｕの許可ＥＵＤｄを応答側から得る悪意を持つユーザＶは、ＵのＰＩＮを知らないために、ドアのところでＵに扮することはできない。前者の保護は権限機関Ａに、応答側許可ＥＵＤｄのカードのＣＵの内部の、Ａに知られている鍵ＳＫＣＵを暗号化した後で、ＥＵＤｄを送らせる事により強制される。このゆにして、ＡはＵのカードのみにより許可ＥＵＤｄに変えられる暗号化された許可ＥＵＤｄ’を応答側に本質的に送って、悪意を持つＶがその日の誰か他の許可をダウンロードすることを無用にする。Ｖが欲する彼自身のカードをなんとか製作したとしても、ＶはＳＫＣＵを依然として知らない。

Ａが秘密鍵ＳＫＤをドアＤと共用すること、および秘密鍵ＳＫＵをユーザＵと共用することがさらに可能である。そうするとＰＵＤｄを、ユーザＵの指示、ドアＤの指示、および日ｄの指示およびあるランダムな秘密ｋ、秘密鍵ＳＫＤで（Ａにより）全て暗号化されている、とより成る値ＥＵＤｄｋとすることができる。（この場合には、ＵはＥＵＤｄｋを解読できないことに注意されたい。）また、ＵはＥｋ、すなわち、ＳＫＵで暗号化されたｋ、を受ける。（ＤとｄはＵに知られているかも知れず、または、例えば、主ドアにおいて同じ応答者により、Ｕへ知らせることができる。）こうすると、ＵはＳＫＵを知るのでＵは秘密鍵を同様に得る。ドアＤに入るために、カードＵはＥＵＤｄｋをＤへ送る。Ｄはランダムな値ｑで応答し、その後でカードＵはＥｑ、すなわち、秘密鍵を用いて暗号化されたｑ、を送る。ドアＤはＥｑを解読し、同じｑが使用されたこと、およびＵがＥＵＤｄｋで指定されたものと同じであること、および日ｄが現在であることを検証し、全ての検査が確認されたならＵを通させる。この機構は上記ＰＩＮ機構を包含でき、それを一層安全にする。ｋを基にした別の問い掛け‐応答法も可能である。（特に、ＤはＥｑの計算と送りおよび正しい解読ｑを繰り返すことをＵに尋ねることができる。）そのような機構は攻撃者がカードとドアの間の通信を傍受したとしても安全である。

しかし、ドアにおいてユーザが入力したＰＩＮを見る敵は、Ｕのカードが内部にＥＵＤｄを有するならば少なくとも間隔ｄの間中、Ｕのカードを盗んだ後でＵを装う。その後で、Ｕが自分のカードが盗まれたことを報告すると、ＡはＥＵＤｄがＵのカードで利用できるようにはもはやしない。

専用鍵(private-key)署名解決策：
例えば、ＰＵＤｄは、ＡとＤが知っている専用鍵ＳＫで、ある定められた専用鍵署名アルゴリズムに従ってＵとｄ（およびおそらくＤも）を指定するメッセージの専用鍵ぎデジタル署名とすることができる。特に、Ｈを一方向ハッシュ関数であるとすると、ＰＵＤｄ＝Ｈ（ＳＫ，Ｕ，ｄ）である。Ｕをカードから受けると、ドアの読取器はＵをそれ自身の専用鍵ＳＫでＵとｄを署名でき、この計算の結果が、カードから得られた列ＰＵＤｄと合致するかどうか比較する。クロックを備えているドア読取器はどれが現在の日ｄであるかを知ることができ、したがって、それをカードから受ける必要はないことに注意されたい。これはＡがある時に１日中アクセスを許可する限り機能する。さもなければ、カードはｄ（または選択された時間間隔）を読取器へまた送り、その後で読取器は得たＵとｄをＳＫでデジタル署名し、その結果がＰＵＤｄと確かに等しいことを調べ、その後で現在の時刻（ドアのクロックによる）がｄ内であることを調べる。もしそうであればそれは開く。

またＵはＰＩＮをトランザクションの一部として入れることを尋ねられる。その場合には、ＰＩＮはＵの一部として使用することもできる。例えば、ＵはｕとＰＩＮで構成できる。ここにｕはユーザを特定する列、ＰＩＮはユーザが知っているパスワードである。その場合には、カードはドア読取器へｕと、ＰＵＤｄ（およびおそらくＤまたはｄと付加量）を転送し、ユーザはＰＩＮを読取器の結合されているドア制御器へ、または読取器自体に入力し、その後で読取器はＵ＝（ｕＰＩＮ）を再構成し、その後でＵｄをＳＫで署名してＰＵＤｄが得られたかどうかを検査する。また、ｄがカードで供給されたとすると、現在の時刻がｄ以内であることも調べる。この方法はユーザと彼のカードをより緊密に結合するので、カードを盗む敵は適切なＰＩＮなしでそれを使用するには長い時間を要する。

もちろん、ドアの集合に同じＳＫを使用することができ、その場合にはそれらのドアのうちの１つをアクセスすることをＵに許可することにより、Ａは全てのドアにアクセスすることを彼に自動的に許可する。アクセス粗さを最大にするために、各ドアＤに秘密鍵ＳＫＤを持たせることができる。

２つの手法を組合わせる：
２つの手法を組合わせる例として、Ｕはｄ日のための秘密鍵ＳＫＵｄをＡから受ける（例えば、上記機構を用いて、特に暗号化を利用する）。その後で彼は秘密鍵署名を用いて彼が本人であることと、彼の許可とのうちの少なくとも一方をドアＤに「証明」できる。すなわち、ドアＤはカードＵにランダムなメッセージを送る。それに応答してカードＵはｍの署名、Ｈ（ｍ，ＳＫＵｄ）、を送る。この署名の計算はＰＩＮｕを要することがあることに注目されたい。その後でドアＤはその署名を検証する。これはドアＤがＳＫＵｄ（例えば、Ａからそれを直接受け、またはなにか他の情報、例えば、Ｈ（ＳＫＵ，ｄ，Ｕ）、等から計算する）を知ることを要する。あるいは、ＡはＤと共用している鍵ＡでＳＫＵｄを暗号化してＥＳＫＵｄを得る。その後でＥＳＫＵｄはＵに与えることができ（例えば、上記のようにして）、その後でＵはそれを署名と一緒にＤへ送ることができる。

多数の機構（組織）：
これまで説明してきたように、どのユーザＵが所与の時間間隔ｄ内でＤをアクセスできるかを管理するためには、機構／権限機関Ａが秘密鍵ＳＫＤをドアと共用することで十分である。このプロセスは、多数の機構Ａ、Ｂ、Ｃ、．．．がドアＤまたはドアの集合Ｄ１、Ｄ２、Ｄ３、．．．へのアクセスを行えるように拡張できる。各機構Ｘは秘密鍵ＳＫＸＤをドアＤと共用し、その後で上記解決策で使用する。例えば、各機構ＸはＳＫＸＤを選択して、それをＤの読取器に差し込むことができる。各機構Ｘは１つまたは複数の被用者／雇われている作業員／請負人／下請け業者の集団をドアからドアへ送らねばならないことがある。しかし多数のドアがある施設でそれを行うことは実際的ではないか無駄である。というのは他の施設が既にそれを行っているかもしれないからである。また、多数の権限機関が存在するか、存在するであろうとすると、読取器はそれらの鍵の全てを保存することが困難なことがある。また、適切な予防措置を講ずるべきである。さもないと、敵が彼自身の秘密鍵をドアの読取器に差し込むことを何者も阻止できず、その後でそれを知ると、彼自身または彼の同伴者がそのドアにアクセスすることを許可する上記方法のいずれかを使用できる。それらの理由から、我々は下記の解決策へ進む。同じ方法を単一の解決策にも同様に適用できることに注意されたい。

第１の解決策：
これまで説明してきたように、ユーザまたはユーザのカードが所与の時間間隔の間秘密鍵を共用しているとすると、彼は安全なドアを通ることができる。したがって、あるやり方でユーザとドアはセッション鍵を共用する。ケルベロス(Kerberos)およびニードハム−シュレーダー(Needham-Schroeder)プロトコルは、エンティティ対が秘密セッション鍵を共用し、全体のシステム内でここに適用できる。しかし、それらのプロトコルはオンラインの鍵配布センターを基にしており、共用されているセッション鍵を必要とする時は常に接触せねばならない。したがって、追加のより便利な方法へ進みたい。まず、ケルベロスおよびニードハム−シュレーダーを基にしたシステムを実現するためにでも、鍵をドアに配布するための中央権限機関のための方法を必要とする（それは鍵を他の権限機関に配布することより困難なことがある）。

鍵をドア読取器に安全に配布するために特殊な権限機関ＳＡを考える（例えば、空港における空港当局者）。ＳＡはそれを行う実体であることが好ましい。例えば、ドア読取器は内部に秘密鍵を有しないと信じられ、最初の秘密鍵群（おそらく単一の鍵の集合）がひとたび挿入されると、読取器はそれを長時間保存し、将来の保存のために他の鍵は受けない。こうすると、いずれかの鍵をドア読取器に挿入する（設置の前、最中、またはすぐ後）最初の鍵により、ＳＡは他の誰も秘密鍵をドアに挿入できないようにする。あるいは、他の秘密鍵をドア読取器に保存するために管理ＰＩＮまたは鍵が必要とされる。ドア読取器は管理ＰＩＮまたは鍵なしで提供され、最初の管理ＰＩＮまたは鍵（または恐らくそれらの集団）が挿入され、その後で読取器はそれを長時間保存し、将来は他の管理ＰＩＮまたは鍵を受けない。しかし、正しい管理ＰＩＮ／鍵が入力されるとすると、どの新しい鍵も読取器に挿入および保存ができる。このようにして、いずれかの管理ＰＩＮ／鍵をドア読取器に挿入する（設置の前、最中、またはすぐ後）最初の鍵により、ＳＡは他の誰も秘密鍵をドアに挿入できないようにする。

この点でＳＡはドアＤの読取器の全ての秘密鍵、例えば、ＳＫＡＤ、ＳＫＢＤ、ＳＫＣＤ、等を知る、ケルベロスを実施するよりも、ＳＡがＳＫＡＤを権限機関Ａに今与え、ＳＫＢＤを権限機関Ｂに今与える、等がより簡単であるかもしれない。この点で、権限機関Ａ／Ｂ／．．．は、秘密鍵暗号化法または秘密鍵署名法によってＤへのユーザＵのアクセスを管理できる。それらの権限機関は種々のドア群を独立に操作できることに注目されたい。例えば、
１．ドアＤ１がそれの読取器内部に秘密鍵ＳＫＸＤ１を持ち、ＳＡがＳＫＸＤ１を権限機関Ｘに与えること、
２．ドアＤ２がそれの読取器内部に秘密鍵ＳＫＸＤ２を持ち、ＳＡがＳＫＹＤ２を権限機関Ｙに与えること、
３．ＳＡはドアＤ１の鍵をＹに与えず、ドアＤ２の鍵をＸに与えない。

その後で、権限機関ＸはドアＤ１へのアクセスを管理でき、権限機関ＹはドアＤ２へのアクセスを完全に独立したやり方で管理できる。

より良い解決法：
しかし利用できる上記諸特徴であっても、上記したものなどのシステムをいくつかの重要な面で改良できる。すなわち、
鍵保存サイズ：ドア読取器は異なるそれを管理する各機構ごとに種々の鍵を保存することが好ましいが、これは読取器が安全に保存せねばならない鍵の数を増大する。

新たな管理を付加する：新しい権限機関または新しいドアがシステムに導入されると、新しい管理の問題が起きることがある。ドアＤが機構Ｘのための鍵を保存せず、かつ後でＸがドアを再び管理することが望ましいとすると、ＳＡはＸのための鍵をＤの読取器に入力せねばならない。例えば、新しい鍵が出ると、ＳＡは新しい機構により管理すべきあらゆるドアＤにＳＫＸＤを挿入するために、作業員のチームを派遣せねばならない。しかし、そのような物理的な「派遣」は不便なことがある。それらを避けるために、ＳＡは付加鍵をドアＤの読取器に予め組み込み、その後でそれらを新たに生じた新しい機構に結び付け、またはＤへのアクセスを後で管理せねばならない機構に結び付ける。しかし、このやり方は最初のビュレットで説明した点を悪化するのみである。さらに、既存のある権限機関により管理すべき新しいドアが導入されるとすると、ＳＡは新しい鍵をドア読取器に挿入し、その後で、適切な秘密鍵をそのドアを管理せねばならない既存の権限機関に供給せねばならない。実行可能ではあるが、常に秘密鍵を供給することは問題である。

管理を取り戻す：秘密鍵ＳＫＸＤがドアＤにひとたび保存されてそれが機構Ｘに知られると、ある点でＤに対する管理を異なる権限機関のみに与えねばならないとしても、ＸはＤのアクセスの管理を続行する。これを避けるために、ＳＡは再び物理的な派遣を行い、ＳＫＸＤをドアＤから除去せねばならない（例えば、管理ＰＩＮ／鍵メカニズムにより）。

ここでそれらの付加改良をどのようにして行うかについて説明する。

基本システムの概観：
最初に、ドア当り１つの鍵で機能するシステムを取り扱うことができる。例えば、ＳＡは１つの鍵をドアＤに保存する（もちろんこの情報を失わないようにする）。その鍵はＤの識別子とＳＡにのみ知られている秘密種ｓとからＳＡにより決定論的に潜在的に計算でき、例えば、ＳＫＤ＝Ｈ（ｄ，Ｄ）、である。その後でＳＡは、ＳＫＤとＸから、例えば、Ｘで計算された種ＳＫＤを持つ疑似ランダム関数として、決定論的に選択された鍵ＳＫＸＤを権限Ｘに与えることにより、Ｄに対する管理をＸに与える（簡単にするために、エンティティがそれの適切な識別子と合致すると全体を通じて仮定する）。特に、我々はＳＫＸＤ＝Ｈ（ＳＫＤ，Ｘ）を持つことができる。その後で前と同様に、権限機関ＸはＳＫＸＤを用いて、ユーザＵにＤをある時間間隔ｄ（例えば、日）の間Ｄをアクセスすることを許可する。特に、ＳＫＸＤを専用鍵署名技術の署名鍵として使用することにより、例えば、ＳＫＸＤＵｄ＝Ｈ（ＳＫＸＤ，Ｕ，ｄ）を計算し、その後でＳＫＸＤＵｄをＵのカードに保存させることにより。ＵのカードがＤの読取器と通信すると、カードは（ａ）Ｘと（ｂ）ＳＫＸＤＵｄ、およびｄ（およびユーザＵについての情報）などのおそらく他の情報を読取器に与える。この情報を受けると、読取器はＨ（ＳＫＤ，Ｘ）を計算し、その後で結果を（ＳＫＸＤに等しいといわれる）同じ専用鍵技術および署名（Ｕ，ｄ）の署名鍵として使用する‐上記例ではそれをＳＫＸＤに組合わせた後で（Ｕ，ｄ）をハッシングすることにより。結果がカードにより与えられた値（ＳＫＸＤＵｄといわれる）と合致すると、時間間隔が読取器クロックに対して正しければ（かつＵが正しいＰＩＮを入れ、ＰＩＮが上記システム内で適切に使用されるならば）、ドアは開く。

鍵保存、管理を加える：
このドア当り単一鍵システムは鍵保存の要求を最小にするばかりでなく、管理を加えるという問題を極めて簡単にする。権限機関Ｘが最初にドアＤを管理することが必要になった時はいつでも、ＳＡはＤに物理的に到達する必要はなく、新しいＤ‐Ｘ鍵をＤの読取器に挿入する（またはＸの挿入を容易にする）。むしろ、ＤがＳＡの知っている鍵ＳＫＤを持っているとすると、ＳＡはＤ‐Ｘ鍵をＳＫＤから単に計算し（例えば、ＳＫＸＤ＝Ｈ（ＳＫＤ，Ｘ））、そのＤ‐Ｘ鍵をＸに与える。

管理を取り戻す：
各ドアＤと、時間間隔（例えば、日）ｄ’の間Ｄを管理する資格を与えられている権限機関Ｘについて、ＳＡはこの事実のそれの署名を計算して使用できるようにする。例えば、この証明書は、ＳＡがドアＤと共用する鍵ＳＫＤに対する専用鍵署名とすることができる。特に、この署名は値Ｈ（ＳＫＤ，ｖａｌｉｄ，Ｘ，ｄ’）とすることができる。専用鍵署名であるとしても、署名自体は案ずることなく公開できることに注意されたい。たしかに、上記の専用鍵署名のＨを基にした実現は、Ｈが安全な一方向ハッシュ関数であるとすると、Ｈ（ＳＫＤ，ｖａｌｉｄ，Ｘ，ｄ’）からＳＫＤを計算することは非常に困難である。したがって、ユーザＵが彼のカードでその日の正しいドア管理許可を取り出すと、彼はドアＤのためにＳＫＸＤＵｄばかりでなくＨ（ＳＫＤ，ｖａｌｉｄ，Ｘ，ｄ’）も取り出す。ドアＤの読取器はその後でＳＫＸＤＵｄを前のように検証し、ＳＫＤ、有効、Ｘおよびｄ，を一緒にハッシングすることにより間隔ｄ，の間Ｄに対する管理をＸが確かに行うことをさらに確認し、カードにより保持されている同じ値が得られるかを調べ、それのクロックに従って現在の時刻がｄ，内であるかを調べる。実際に、ＳＡ（およびＤ）のみが秘密署名鍵ＳＫＤを知り、権限機関ＸがＨ（ＳＫＤ，Ｘ）を知るが、Ｈ（ＳＫＤ，Ｘ）とＨ（ＳＫＤ，ｖａｌｉｄ，Ｘ，ｄ’）からＳＫＤを計算することは非常に困難である。時間間隔ｄとｄ，は同じではないことがあることに注意されたい。例えば、週ごとにＤを管理する許可をＸに与えるためにＳＡを満足させることができるが、Ｘは毎日Ｄに対するアクセスの許可をユーザに与えることができることに注意されたい。あるいは、このシステムは上記のようなＳＫＸＤの使用の代わりにその鍵の時間に依存するもの、例えば、ＳＫＸＤｄ＝Ｈ（ＳＫＤ，Ｘ，ｄ）を使用できる。そうするとＳＡは、時間期間ｄより前に、ＳＫＸＤｄを各権限機関Ｘに供給せねばならない。管理を取り戻すために、ＳＡはＸのドアＤに対する管理を否認することを決定する期間の間、ＳＡはＳＫＸＤｄを送ることを単に停止する。

また、このシステムは隠しておきたいある私的なことを現在許しており、ＳＡはどのユーザＵがＤにアクセスすることをＸにより許されているかや、それの数は知る必要はないことに注意されたい。このやり方は、（例えば、知らせたり、ケルベロスシステムを用いることにより）もちろんこの私的なことを除くことができる。

例１４：
ここで、スーパー権限機関ＳＡと、多数の（なるべく切り離されている）ドアＤと、多数の機構Ｘと、多数のユーザＵとを取り扱うシステムにおいて安全な物理アクセスを行う我々の好適な実現の概略を説明する。この好適な実施形態は鍵の保存を最小にして、機構ＸがドアＤの管理を付加したり、取り戻すことを非常に容易にする。

好適な実施形態では、ＳＡは機構ＸがドアＤを所与の時間間隔の間管理することを許可する。その時間間隔中は。Ｘ自体はユーザＵにドアＤへのアクセスを許すことができる。

一連の時間間隔に対応する一連の日ｄの各日にＳＡ（およびおそらく他の関与するもの）が動作を起こすと考える。例えば、ｄを所与の日の初めとし、対応する時間間隔を所与の日とすることができる。簡単にするために、日と対応する時間間隔を意味するためにｄを使用することがある。（しかし、これは限定するものではないことを理解すべきである。例えば、ある日付を所与の日とすることができ、その日付に対応する時間間隔は続く日とすることができる。）具体的には、限定する意図無しに、各日付／時間間隔は日であると仮定する。

専用鍵デジタル署名を用いる好適な実施形態について説明する。これはいかなる限定も意図しない。好適な実施形態は上で説明した他のいかなる専用鍵システムでも実現できるものと考えるべきである。より具体的には、専用鍵署名は一方向ハッシュ関数Ｈを用いて実現されるものと仮定する。これは限定することを意図しない。Ｈ（ＳＫ，ＤＡＴＡ）はＤＡＴＡの鍵ＳＫでのデジタル署名であると常に考えるべきである。

ＳＡは秘密鍵ＳＫＤをドアＤと共用していると仮定する。ＳＡは秘密鍵ＳＫＤを機構Ｘとも共用することがある。（ＳＫＤはＡにより主秘密鍵ＳＫを介して生ずることができる。ＳＫＸに対しても同様である。例えば、ＳＫＤはＨ（ＳＫ，Ｄ）に等しくでき、ＳＫＸはＨ（ＳＫ，Ｘ）に等しくできる。そうするとＳＡはＳＫＤをＤに私的に‐または暗号化により‐与えることができる。Ｘに対しても同様である。）
各ｄ日に、ＳＡがドアＤをアクセスする許可を機構Ｘに与えることを望んだとすると、それは計算して秘密鍵ＳＫＸＤｄ、すなわち、Ｘ、Ｄ、およびＤにより検証できる（例えば、入力Ｘとｄで）日ｄに確実に結び付けられている鍵、をＸに受けさせる。

例えば、ＳＫＸＤｄ＝Ｈ（ＳＫＤ，Ｘ，ｄ）、すなわち、ＳＡが鍵ＳＫＤでＸ、ｄに署名する。その後でＳＡはＸにＳＫＸＤｄを受けさせる。ＳＡは、好ましくは、Ｘと共用している秘密鍵ＳＫＸでＳＫＸＤｄを暗号化した後で、ＳＫＸＤｄをＸへ送ることによりＸにＳＫＸＤｄを受けさせることがある。さらに好ましくは、ＳＡは、ＸにＳＫＸＤｄを応答者に保存させることにより、そのように暗号化されたＳＫＸＤｄをＸへ送る。その後でＸは応答者からそれをダウンロードする。

ｄ日内の時間間隔ｔに、ＵがドアＤをアクセスする許可をＵに与えることを望んだとすると、Ｘは計算して秘密鍵ＳＫＸＤｄＵｔ、すなわち、Ｘ、Ｄ、ＵおよびＤにより検証できるｔに確実に結び付けられている鍵、をＵに受けさせる。

例えば、ＳＫＸＤｄＵｔ＝Ｈ（ＳＫＸＤｄ，Ｕ，ｔ）、すなわち、Ｘが鍵ＳＫｘＤｄＵｔでＵ、ｔに署名する。その後でＸはＵにＳＫＸＤｄＵｔを受けさせる。Ｘは、好ましくは、Ｕと共用している秘密鍵ＳＫＵでＳＫＸＤｄＵｔを暗号化した後で、ＳＫＸＤｄＵｔをＸへ送ることによりＵにＳＫＸＤｄＵｔを受けさせることがある。さらに好ましくは、Ｘは、ＸにＳＫＸＤｄＵｔを応答者に保存させることにより、そのように暗号化されたＳＫＸＤｄをＵへ送る。その後でＵは応答者からそれをダウンロードする。

Ｕが時間間隔ｔでＤをアクセスすることを望んだとすると、ＵはＤにＸ、Ｕ。ｔを受けさせる（例えば、ＵのカードがＤの読取器へ転送する）。

Ｄがｄ日にＸ、Ｕ、ｔを受けたとすると、それはそれの秘密鍵ＳＫＤからＳＫＸＤｄＵｔを計算する。その後でＤは時間間隔ｔが確かにｄ日内であることを検証し、それ自身のクロックを用いて現在の時刻が確かに時間間隔ｔ内であることを検証する。さらに、鍵ＳＫＸＤｄＵｔを用いる問い掛け‐応答メカニズムによりそれがＵ／Ｕのカードを取り扱っていることを検証する。それらの検証に合格すればＤは開く。

例えば、ＤはＨ（ＳＫＤ，Ｘ，ｄ）を計算することによりＳＫＸＤｄをそれの秘密鍵ＳＫＤから計算でき、その後でＨ（ＳＫＸＤｄ，Ｕ，ｔ）を計算することによりＳＫＸＤｄＵｔをそれの秘密鍵ＳＫＤｄから計算できる。例えば、ＳＫＸＤｄＵｔを用いる鍵問い掛け‐応答メカニズムはＤがランダムな列ｑを送り、鍵ＳＫＸＤｄＵｔによるｑの暗号化、または鍵ＳＫＸＤｄＵｔによるｑのデジタル署名を受け戻す。あるいは、ＤはＥｑと鍵ＳＫＸＤｄＵｔによるｑの暗号化を送ることができ、ｑを受け戻ねばならない。

この好適な技術は上記とともにＰＩＮを使用することを含むことを理解すべきであることに注意されたい。特に、前の節で述べたＰＩＮはこの好適な実施形態で使用できる。この好適なシステムはｄとｔを異ならせることができるという点で大きな融通性をもたらすことに注意されたい。例えば、ＳＡはＸがＤを１週間ｄの間中管理できるようにし、ＸはＵがドアＤを１週間ｄのうちのｔ日アクセスできるようにすることができる。しかし、ｄ＝ｔのことがあり、その場合にはこの好適なシステムではｔを指定したり、別々に使用する必要はない。

ケルベロスの手法：
ケルベロスの手法を直接用いることは我々の安全アクセス用途では非常に良くは機能しない。全てのドアとＳＡを１つの部門として実現することが最も自然である（その部門ではＳＡを入場券交付サービス、ＴＧＳ、として機能する）。そうすると各機構およびその被用者は別々の部門である。そうなると各機構の権限機関はその部門に対する認証サービス、ＡＳ、（およびおそらくそれ自身のＴＧＳ）として機能する。ケルベロスのプロトコルに従って、各ユーザは、入場券交付券、ＴＧＴ、を得るそれぞれの権限機関／ＡＳに対して認証する。このチケット（券）ＴＧＴはその後で、ユーザがアクセスする資格を与えられている各ドアに対するサービス提供券に対する要求と一緒に、ユーザによりＳＡ／ＴＧＳへ送られる。そうするとＳＡ／ＴＧＳはユーザの資格を検証せねばならず、かつもしユーザが‐全てが正しければ‐それらのサービス提供券を提供するならば。このプロトコルは明らかに全く困難であり、ＳＡに負担の多くを掛ける。特に、特定のユーザにどのドアをアクセスする資格が与えられているかを検証することと、それぞれのチケットを発行することはＳＡの責任である。さらに、ＳＡがオンラインであることと、リアルタイムでプロトコルを使用することをこの手法は求めている。ＳＡへのユーザチャネルを有することは安全に対する脅威をさらに増大する。

プロトコル無しのケルベロスチケット
原則として、我々はケルベロスプロトコルを「放棄」でき、チケットを使用するのみである。すなわち、全てのチケットは先に予め注文して前もって計算され、ユーザは、適切なケルベロスプロトコルの関与無しに、主ドアに入る際にそれらのチケットを受け取る。

しかし、上記問題の多くはそのまま残る‐特に、ＳＡがあるドアの管理を特定の権限機関に委任することは自然である（しかし、この管理が容易に取り戻せ、おそらく後の点で元に回復されるようにして）。

ケルベロス内でＲＴＣを利用すること
この問題の対処を支援する１つのやり方はリアルタイム証明書、ＲＴＣ、を利用することである。例えば、上記のやり方のようにしてチケットを使用できる。しかし、このやり方では、チケットを毎日発行できないことがある。その代わりに、チケットの許可データフィールドに設けられているＲＴＣを介して短期アクセス管理を取り扱う長期チケットを使用できる。

この場合にはＲＴＣは公開鍵証明書の場合におけるのと全く同じように機能できる。しかし、ここでは同様にいくらかの最適化が可能である。

上記のようにしてＲＴＣを利用するといくつかの可能な利益がもたらされる。それらには、
１．管理の容易さ：
ａ．今は、ＳＡは比較的たまに関与せねばならない、
ｂ．比較的大きなチケットの代わりに、ユーザははるかに小さいＲＴＣを取り出す必要がある、
ｃ．ＲＴＣの発生は対応する権限機関委任できる、
ｄ．管理の取り戻しが容易である。これは少なくともふたとおりのやり方で行うことができる。第１に、一層簡単かつ不完全である‐チケットは出た後でＳＡにより更新できないことがある。より精巧になったメカニズムは２種類のＲＴＣ、ＳＡにより出されるものと、他の権限機関により出されるもの、を利用する。そうすると各日にＳＡは各権限機関ごとに１つのＲＴＣを出す必要がある。それはそのままである（あるいは、各権限機関‐ドア対ごとにＲＴＣを出さねばならないかもしれない、この場合にはＲＴＣはドアを開く資格を与えられている）。各権限機関は各ユーザごとに、ＲＴＣをまた出す（あるいは、ユーザ‐ドア対ごとに、この場合にはユーザはドアを開く資格を与えられている）。注意、より従来のケルベロス手法はより多くのチケットを発行して、オンライン・プロトコルで次々に回されることを求める、
ｅ．ＲＴＣは役割をはっきり分けて、管理および下部構造の多くの面を容易にする。

２．効率：
ａ．スペース：ＲＴＣは対応するチケットよりはるかに小さい、
ｂ．時間：それらははるかに短く（そしてそれらは少なく、全体の通信の数も少ない）ので、通信ははるかに速くて、ＲＴＣを妥当なペースでピックアップしている間にユーザはドアを通ることができるようにされる、
ｃ．負荷分散：ＲＴＣは安全でない応答者により分配できる。ＲＴＣの応答は費用も少なく、危険でもない。

３．セキュリティ：
ａ．ＲＴＣはセキュリティに敏感でなく、ひとたびそれらが発生されると、セキュリティに対する何等の脅威もなしに極めて容易に管理できる（例えば、安全ににされていない応答者により）、
ｂ．チケットと権限機関の分離（ＲＴＣによる）によって鍵管理のセキュリティが極めて高くなる（鍵／チケットが実際に発生されて通信された時）、
ｃ．ＳＡ分離：ＳＡはユーザのいずれに対しても直接の通信線を引く必要は実際に決してない。

ケルベロスを越えて：
上記メカニズムは核となるケルベロスの機能から得る利益はかなり少ないことが観察できる（この理由の大きなものは、ケルベロスが種々の用途のために構成されたためである）。したがって、ここではケルベロスに直接関連していない、ＲＴＣを基にしたメカニズムをどのようにして利用できるかをさぐることにする。それらのメカニズムは上記専用鍵暗号化メカニズムおよび専用鍵署名メカニズムに類似することがある。

それらのメカニズムでは、特殊な権限機関ＳＡが秘密を各機構Ａ（Ｂ，Ｃ，...）および各ドアＤと共用する。これは、例えば、ＳＡが単一の秘密ｓのみを保存する必要があるように上記方法を用いて行うことができる。そうするとＳＡとＡの間で共用される秘密はＳＫＤ＝Ｈａｓｈ（ｓ，Ａ）である。同様に、ＳＡとＤの間で共用される秘密はＳＫＤ＝Ｈａｓｈ（ｓ，Ｄ）である。ＡとＤもただ１つの秘密、それぞれＳＫＡまたはＳＫＤ、を保存する必要があることに注目されたい。また、各機構‐ドア対（Ａ，Ｄ）に追加秘密ＳＫＡＤ＝Ｈａｓｈ（ＳＨＤ，Ａ）が対応する。この秘密はＳＫとＤにより容易に計算できる。ＳＫＡＤをＡに与えることは必要であるが、Ａがドアへのアクセスを管理するにはおそらく十分ではない。また、Ａは現在の時間期間ｄの間中はＲＴＣをＳＡＫから（または他のものから）受ける必要がないことがある。ＲＴＣＡｄと名付けられるこのＲＴＣは秘密である必要はなく、ＡがＳＡに対して良い立場に依然としてあることを証明できる。

Ａにより採用されて、ドアＤに入る資格を与えられている各ユーザＵは、その後で鍵ＳＫＡＵＤ＝Ｈａｓｈ（ＳＫＡＤ，Ｕ）をＡから受ける。ＳＫＡＵＤはいかなる付加秘密もなしにＡとＤにより容易に計算できる。ＳＫＡＵＤをＵに与えることは必要なことかもしれないが、ＵがドアＤを開くことができるためには多分十分ではない。また、Ｕは現在の時間期間ｄの間別のＲＴＣ、ＲＴＣＡＤｄ、を必要とするかもしれない。

この手法は情報の流れを既に劇的に簡単にしていることに注目されたい。各時間期間ｄの間、ＳＡは単一のＲＴＣＡｄを各ユーザ‐ドア対へ送る。それらのＲＴＣの全ては主ゲートに入る被用者によりピックアップできる。あるユーザＵが施設内の１００のドアを入る資格を与えられていると仮定すると、ＲＴＣＡＵＤｄの全てのドアは２ＫＢより少なく要することがある。これは遅い（通常は、秒以下を要する）接続でも管理できる量である。

ドアＤを開くために、ユーザＵはＲＴＣＡｄとＲＴＣＡＵＤｄを提示することと、秘密ＳＫＡＵＤを基にして認証を行うことを必要とすることがある（その認証は秘密を保護するために問い掛け‐応答型とであることがある）。注意：このシステムでは比較的少数のＲＴＣＡｄ証明書が提示されがちであるので、それらの証明書のバリデーションはユーザごとに行う必要が無いことがある。その代わりに、他のユーザのバリデーションに使用するために、各ドアはそれが受ける各ＲＴＣＡｄをバリデートして、結果をキャッシュすることがある。

特殊な権限機関ＳＡがドアに対する機構のアクセスをより細かく管理することを望むことがある。それを行うために、機構証明書ＲＴＣＡｄごとの代わりに、ＳＡは各機構ドア対（Ａ，Ｄ）：ＲＴＣＡＤｄごとにＲＴＣを出すことがある。そうすると毎日各機構によりＳＡに許可を与えて、各ドアに対する管理を取り戻すことが可能である。これは各ユーザが受ける必要があるＲＴＣデータの量をせいぜい２倍にすることがあることに注意されたい（上記例について求められる遷移時間を秒以下に依然として保っている）。

集合ＲＴＣ：
アクセス管理権は日ごとに劇的に変わることはしばしばはないことを観察できる。したがって、上記メカニズムのパワーの多くは利用されない。我々はＲＴＣ集合メカニズムを提案する。それはそのように比較的安定な環境において効率を一層高めるために利用できる。

例１５：
例として、おのおの１０００のドアをアクセスする１００の機構の場合について考えることにする。したがって、１０００００の機構‐ドア対があり、そのためにＳＡが毎日発行して配布する１０００００のＲＴＣＡＤｄ証明書がある。さらに、各機構が約１０００人の人を採用しているならば、これは１００００００００のＲＴＣＡＤｄ証明書を全ての機構が発行して配布することになる。

機構‐ユーザ‐ドアの三っ組ＡＵＤ，ｓの全てを階層的に配列されている群に分割することにする。全てのＡＵＤ，ｓを平衡されている２進木の葉（好適なやり方で順序付けられている）に対応させる。そうすると木の各節は、ｎのサブ木の葉に対応するＡＵＤ，ｓの集合に対応する。そのような各節と時間期間ｄに対して、証明書ＲＴＣｎｄも対応する。そうすると期間ｄ中のＡＵＤ三っ組のバリディティを、ＡＵＤの先行するものｎのいずれかにに対して、証明書ＲＴＣｎｄのいずれかにより証明できる。ｄ日にＡＵＤ三っ組が有効なままであるならば、単一の証明書ＲＴＣｒ，ｒは木の根、はシステム全体に対して十分である。

一般に、無効になる１００のＡＵＤ三っ組があるならば、システム全体を証明するためには１５００の証明書で十分である（すなわち、１００００００００の代わりに）。より一般的には、ｋの三っ組が無効であるならば、たかだかｋ（２６−ｌｇ ｋ）の証明書をシステム全体の証明のために必要とする。

この方法は、集合ＲＴＣ，ｓがドアとユーザの少なくとも一方に保存すべき値をもっと多く要するとしても、劇的な改良が行われることがある。上記の例では、そのようなオーバヘッドは記憶装置においてせいぜい２６の係数のオーバーヘッドとなる結果になることがあるが、通信量は何桁（上記例では４桁または５桁）も減少する。より一般的には、許可すべき全てのエンティティの集合（我々の例では、それはＡＵＤ三っ組）がＮ個の要素を含んでおり、それらのうちのｋを除外すべきであるとすると、システム全体を証明書するためにはたかだかｋ（ｌｇＮ−ｌｇ ｋ）の証明書を必要とし、集合のためのオーバーヘッドはたかだかｌｇＮのことがある。集合の一層効率的な表現が文献にある（例えば、上記はサブセットカバー法として知られているが、我々はサブセット‐差カバーとそれについての最近の結果のいくつかも用いることがある）。したがって、このような集合証明書のバリデーションは、例えば、少なくともより大きい集合のために結果をキャッシングすることにより、最適にできることがある。

ＲＴＣ実装および最適化：
リアルタイム証明書のために多数の異なる実現が可能である。ＲＴＣのそれらの実現は多くの種々の最適化も行えるようにする。例えば、リアルタイム証明書を次のように実現することができる。ｘ₀をランダムな値、例えば、２０バイト長さ、にする。ｘ_iをｘ_i＝Ｈａｓｈ(ｘ_i)と定義する。ｘ_nを何等かのやり方で固定された（例えば、ＳＡからドアＤへ確実に伝えられる）公開値とする。そうすると、ｘ_n-dは時間期間ｄの間リアルタイム証明書ＲＴＣｄである。それはＨａｓｈ()をｘ_n-dにｄ回適用することにより検証でき、結果がｘ_nに等しいことを検証する。これはほぼ、公開鍵証明書の場合にＲＴＣがどのようにして実現できるかである‐例えば、証明書の一部としてｘ_nを含むことができる。

これとほぼ同じ実現を使用することが可能である。証明書の内部にｘ_nを含む代わりに、ここでは我々はそれをケルベロスチケットの一部として含むことができる。または、ドアＤのための秘密鍵ＳＫＤで暗号化する、等などの、他の安全な方法でそれを通信できるかもしれない。

ＲＴＣｄのその他の可能な実現はそれをＨａｓｈ（ＳＫＤ，ＲＴＣ，ｄ）に等しく単にセットすることである。ここにＲＴＣは証明書ＩＤを指す。例えば、機構Ａがｄ日にドアＤの管理を行えるようにするために、証明書ＲＴＣＡＤｄが使用される。ここにＲＴＣＡＤｄはＲＴＣＡＤｄ＝Ｈａｓｈ（ＳＫＡＤ，ｄ）にセットできる。ユーザＵがｄ日にドアＤをアクセスするための、機構Ａにより発行された証明書はＲＴＣＡＵＤｄ＝Ｈａｓｈ（ＳＫＡＤ，Ｕ，ｄ）とすることができる。そのような方法によって証明書を特定の日付に対して十分前に予め発行できるようにし、しかも所望の時間期間外のいかなる日にもアクセスを許可することはない（それらが隣接していたとしても）。

上記証明書のバリデーションは直線的である。上記証明書は適切な鍵を持つほぼ対称的な署名であることに注意されたい。上記の全てにおいては、暗号化をＨａｓｈの代わりに使用できる。

我々はシステムを構築し、各ステップで一層効率的であることに注意されたい。１０００のドアと１００の権限機関が設けられ、ほぼ１００００人の労働者が働いている空港について考え、簡単にするために管理が毎日をベースとして行われると仮定する。そうすると中央権限機関が各ドア‐ユーザ鍵の計算に含まれているケルベロス／ニードハムーシュレーダーシステムは１日当り１億の秘密鍵に包含されるはずである。上で概略を述べたシステムは、１日に１０００００より少ない秘密鍵を発生して、それを全ての権限機関へ供給するためにＳＡを要する。

ＯＣＳＰを超えるリアルタイム証明書：
ここで、デジタル証明書バリデーションのためのオープン証明書状態プロトコル(Open Certificate Status Protocol)（ＯＣＳＰ）を使用する環境内でのリアルタイム証明書バリデーションのために本発明の好適な実施形態の使用について説明する。これは本発明の技術がＯＣＳＰ規格との互換性をどのようにして維持し、しかも従来のＯＣＳＰ実現よりも質的に優れたセキュリティと大規模化の可能性を提供することを示す。

従来のＯＣＳＰの実装：
ＣＲＬは、一緒にまとめられた多数の証明書についての無効の（およびしたがって、間接的に、バリディティの）証明を提供するので、大きく成長することがある。対照的に、ＯＣＳＰは個々の証明書のバリディティの証明を提供する。ＯＣＳＰのサービスはＯＣＳＰ応答者により通常実現される。そのような応答者はサーバであって、このサーバは所与のＣＡにより出された所与の証明書のバリディティについてのクライアント（依頼側ともいう）からの照会を受けると、証明書の状態と応答の時刻を示すデジタル署名された応答を提供する。これを行うためには、ＯＣＳＰ応答者がＣＡの証明書の全ての状態を知る必要がある。その理由はＣＡ自身の証明書を無効にできるのがＣＡだからである。ＯＣＳＰ応答者がＣＡ自体であるとすると、その知識は平凡に獲得される。さもなければ、ＣＡの証明書の状態についてＯＣＳＰ応答者を更新されたままにする何か別の態様を採用せねばならない。例えば（米国特許第５７１７７５８号、証人を基にした証明書無効システム(Witness-Based Certificate Revocation System)参照）、ＣＡはそれの最近のＣＲＬを応答者へ送ることができ、応答者は、対象とする証明書が現在有効であるか無効にされたかを演繹するために署名されたドキュメントを参考にし、それの署名された応答でそのように言い、時刻と次の更新の時刻を示す。（ここではこの更新時刻がＣＡの次のＣＲＬの日付と一致することが自然である。その理由は異なる応答をトリガすることができるのはＣＲＬであるからである）。

もちろん、悪意のある応答者が所与のＣＡの証明書についての随意に署名された応答を、後者のＣＲＬｓと協議して、または協議なしで、与えることができる。信頼している側が所与のＣＡの証明書についてのＯＣＳＰ応答者のデジタル署名された応答を確実に信頼するために、ＯＣＳＰは、応答者に応答者証明書‐ＣＡにより署名された‐特殊なデジタル証明書、をＣＡが与えること、ＣＡが応答者を信頼してそれの証明書についての正確な証明を与える事を他の側にほぼ証明することを考察する。

このプロセスが機能するために、各ＯＣＳＰ応答者（およびあらゆるＣＡ）は秘密署名鍵を持たねばならず、この鍵は保護しなければならない（理想的にはそれを置いたり、サーバが金庫内でそれを使用することにより）ことに注目されたい。

図２は些細なＯＣＳＰ環境におけるこのトランザクション・シーケンスを示す。秘密署名鍵が保護されるという事実が、それらを何か濃い「ボーダー」を掛けることにより図形的に強調している。署名されたデータの場合には、署名者の名前がすぐ下に示されている。この図はこのトランザクションの種々のＰＫＩ感知要素を陰影をつけられたボックスとして示す。認証局自体は、証明書の無許可発行および無効化を阻止するために、安全に保持せねばならない専用鍵、ＳＫＩ、を持つ。この鍵はＯＣＳＰ応答者に公開されているＣＲＬを署名するために用いられる。応答者１Ａの秘密鍵も安全に保持せねばならず、かつ応答者１ＡのＯＣＳＰ応答を署名するために使用される。

ＯＣＳＰの欠点：
欠点１：計算量：
デジタル署名は計算集中的な操作である。各応答ごとに応答者により行われるデジタル署名は要求があった時に発生され、それはバリデーション操作の最も計算集中的な部分である。それはトランザクション時間にどこでも５０ミリ秒から１秒まで容易に付加できる。

応答者がデジタル証明書についてのそれのデジタル署名をキャッシュし、その後でＣについて尋ねられた時に同じ署名を送ったとしても、Ｃについて尋ねた最初のユーザに対する応答は依然として大きく遅延させられる。

欠点２：（集中化した実装での）通信：
単一のバリデーションサーバがＯＣＳＰを集中化したやり方で実現すると仮定する。その後で、全ての証明書‐バリディティ照会を、最終的に、それへ選択した経路で送らねばならず、そうすると、図３に示すように、サーバはかなりの混雑と遅延をひき起こす大きな「ネットワークの隘路」となる。極めて多数の正直なユーザがサーバに突然照会したとすると、混乱を生ずる「サービスの拒否」がおそらく続く。

欠点３：（分散化した実装の場合の）セキュリティ：
集中化したＯＣＳＰ実現がひき起こすことがある隘路（ボトルネック）問題を阻止するために、ＣＡはそれの証明書により発生された要求負荷をいくつかのＯＣＳＰサーバ（それが適切に証明する）に分配することにより、その負荷を分配することを考えることがある。一般に、単一のサーバの負荷を、世界中に戦略的に配置されているいくつか（例えば、１００）のサーバの間に分配すると、ネットワークの混雑が軽減される。しかし、ＯＣＳＰの場合には、負荷を分配するとそれが解決しようとする問題よりも悪い問題をひき起こす。それが受けた証明書照会に対するそれの応答に署名するために、１００のサーバのおのおのはそれ自身の秘密署名鍵を持たねばならない。そうすると、１００のサーバのいずれもうまくまとめることによってシステム全体が効果的にまとめられる。

従来のＯＣＳＰ応答者がまとめられたとすると、攻撃者は３つの事のうちの１つを行うことができる。まず、それは応答者がどのような応答を出すことも阻止できる。この種の攻撃は信頼する側の所で検知できるのであまり厳しいものではない。第２に、それは発見された秘密署名鍵を使用して、真正な証明書が無効にされたことを示す応答に署名する。第３に、それは、無効にされた証明書が依然として有効であることを示す署名された応答を応答者に発生させることができる。この種の誤りが顕著な応答によって雇用が終了した被用者がシステムへのアクセスを再び得ることができるようにすること、等が起き得る。

応答者が危険にさらされることがあることを阻止する最良のやり方は、２４Ｘ７の監視付きの、安全金庫等からそれを動作させることである。不幸なことに、これの実行には高い費用を要する。金融ＣＡに求められる全ての要求を満たす真に安全な金庫は、建設に１００万ドル以上、運用に１年当り１００万ドル以上もの費用がかかることがある。そのような出費を厭わないとしても、金庫は一晩で建設できず、強化されたコンクリートははがれない！ＣＡの現在の応答者の負荷を軽くするためにＣＡがもう少し多くの金庫を必要としたとすると、新しい金庫を建設できるまで何か月も待たなければならない。

さらに、費用の掛かる金庫がいくつかあったとしても、それらは依然として安全ではないかもしれない。その理由は、ＯＣＳＰのメカニズムが、応答者が信頼できない源（現場の顧客）から来る要求を受け、その後で秘密署名鍵を用いてそれらのために業務を行うことを求めるからである。したがって、悪意を持つ者が運用中のシステムの何等かの弱点につけこんで秘密署名鍵を暴露し、夜間に強化コンクリート外壁に穴をあけるという可能性が存在する。要するに、金庫が全く無いか、十分に費用を要する応答者防護外壁が無ければ、危険にさらされる確率が非常に高くなり、しかも真に安全な建物内に応答者が設けられたとしても、応答者はソフトウエア攻撃や、技術に優れたデジタル敵などには依然として攻撃されやすいので、ＯＣＳＰメカニズムは金庫を「窓」付きのバンカーに非常に良く似たものにする。

欠点４：信頼の流れ：
ＯＣＳＰは種々の安全領域から出された証明書バリディティ要求を処理することが困難である。図４に示されているシナリオでは、機構＃１によって動作させられている応答者はＣＡ＃１からの証明書の状態についての応答を提供できるが、別の機構により動作させられている応答者は「外部の」証明書についての応答を提供するために十分な情報を持っていないことがある。例えば、認証局ＣＡ２により動作させられている応答者２ＡはＣＡ１の証明書についての要求にどのように答えるかを知らない。

特定の知識が欠けているために生ずるこの問題は２つのやり方のうちの１つで対処できる。

第１に、機構＃２からの依頼人は、機構＃１からの応答者にＣＡ＃１からの証明書の状態について照会するために、応答者を探すことがある。しかし、機構＃１からの応答者は機構＃２に関連する依頼人から地理的に遠いことがあるので、ネットワークを経由する時間が長くなってバリデーション全体の処理が極めて遅くなることがある。

第２の方法は、ＣＡ＃１がそれのＣＡＲＬｓを「外部の」応答者へも送ることにより、機構＃２からの応答者が機構＃１からの証明書についての応答を行わせることである。この場合にはＣＡＲＬｓはデジタル署名され、かつＣＡが最大の考えられる客にそれ自身の証明書のバリディティについて知らせることを望むので、それは確かにセキュリティへの脅威とはならない。これは、依頼人からのＣＡ１の証明書についての要求に答えるために、機構＃２の応答者に十分な情報を提供する。しかし、依頼人が応答者２Ａのデジタル署名された答えを実際に重大なものと取るようにするために、ＣＡ１は応答者２Ａをそれ自身の証明書についてのバリディティ照会に答えるために信頼に値するものとしてまた証明せねばならない。全体のプロセスが図５により示されている。

この手法はより良い大規模化可能性と性能を提供するが、２つの機構の間のセキュリティと信頼をあいまいにする。上の例では、応答者＃２は、ＣＡ＃１の証明書＃３２１が依然として良いという許可応答を依頼人に対して行う。何等かの理由で（構成の誤り、敵意のある攻撃、またはむき出しの不正直）不正確な応答を行うと、応答者２Ａは機構＃１からのユーザに悪い結果をもたらすことがある。応答者＃２Ａがそれ自身の証明書についての許可請求を行えるようにすることにより、機構＃１はそれが以前に保持していた信用のいくらかを放棄する。

例として、機構がクレジットカード発行者である場合について考えることにする。銀行＃１がユーザ＃３２１に対するカード証明書を無効にし、それの応答者が安全かつ信用できるようにするために支払う。銀行＃２からの応答者が誤って構成されているので、商人である依頼人がユーザ＃３２１のバリディティについて照会すると、ユーザが有効であると不正確に応答する。商人はこの答えを受け、無効にされたユーザのためにトランザクションが進行できるようにする。

機構間のこの種の信頼の委任はある場合には許容できるが、従来のＯＣＳＰの大規模で雑多な拡張の一般に有用な代替ではない。

ＯＣＳＰを介したリアルタイム証明書：
上記諸問題にかんがみて、我々は代わりの証明書バリデーションシステムを提供する。リアルタイム証明書（ＲＴＣ）は、現在のＯＣＳＰとの互換性を保ちながら、従来のＯＣＳＰの上記諸欠点の全てを解決する。ＲＴＣ技術は次の点で従来のＯＣＳＰとは異なる。

１．外部の応答者に信頼を委任しない、
２．全てのバリディティ信頼を単一の権限機関（ＲＴＣ権限機関）に集中する。さらに、
３．この１つの権限機関から照会負荷を任意の数の保護されていない応答者を通じて分配する、
４．何千もの応答者（かつそれらの応答者が保護されていないとしても）に依存している分散実現においてさえもセキュリティを減じない、
５．照会に対する応答時間を劇的に短縮する。

これはセキュリティと、性能と、大規模化可能性と、多様性との面で従来のＯＣＳＰより極めて大きく改善する。

ＲＴＣシステムは下記のステップを備えている。

ＣＡがＲＴＣＡを証明する：この新しいシステムはＲＴＣ権限機関（ＲＴＣＡ）の周囲に集中させられる。これは所与の機構のＣＡに一致するか、一致しないことがあるエンティティである。各ＣＡはそれ自身のＲＴＣに特殊な証明書、すなわち、ＲＴＣＡ証明書、を与えることが好ましい。ＣＡはこの証明書をデジタル署名することが好ましい。それはＲＴＣＡを信頼していることと、それ自身の証明書についての証明書バリディティ情報を提供する権限をＲＴＣＡに与えることを示す。そのような証明書は所与の検証鍵ＰＫ（それに対してＲＴＣＡは対応する秘密署名鍵を有する）をＲＴＣ権限機関（例えば、所与の識別子、ＯＩＤ番号）に結び付け、その証明書がＲＴＣ状態をほぼ協議することをあるやり方で指定し、かつ他の従来の証明書情報およびフォーマットを含むことがある。２つのエンティティが一致する場合には、それらが異なる署名鍵を持つことがそれらにとって依然として有利であり、したがって、実際には、いかなる場合にもＣＡは証明書を出すのみであり、ＲＴＣ権限機関はそれらを管理するだけで（すなわち、それらが有効であるか無効にされたかを証明する）。これは、ＣＡとＲＴＣＡが一致したとしても、そうであり、ＲＴＣＡ証明書を依然として採用できる。各ＣＡはただ１つのＲＴＣを持つことが好ましく、冗長性を持たせるために、同じ署名鍵を使用するか否かにかかわらず、複数持つことが有利なことがある。

ＲＴＣＡがそれの署名鍵を保護する：ＲＴＣＡは、例えば、金庫または安全設備によりそれの署名鍵を保護せねばならない。（しかし、後で分かるように、証明書バリデーション目的のためには付加金庫の必要はない！）。ＲＴＣＡは、同じ保護されている施設内でそれの秘密署名鍵を組み込んでいる２つ以上のサーバを主催し、または鍵のコピーを安全に保存し（例えば、銀行の安全セキュリティ金庫に）、またはＣＡにより適切に証明されている秘密署名鍵をおのおの有する２つ以上のサーバを主催する。

ＣＡがそれの証明書の状態をＲＴＣに知らせる：例えば、それは証明書バリディティのいかなる変化もオンライン／リアルタイムのやり方でそれを評価したままにする（証明書の状態変化が起きた時にそれを知らせるメッセージをＲＴＣＡへ直ちに送るなど）。あるいは、それはそれのＣＲＬｓが発生された時にそれをＲＴＣＡへ送ることができる。

ＲＴＣＡが所与の時間間隔の間各証明書のバリディティ状態を、いかなる要求とも独立に、個々に署名する：なるべく定期的に（または一連の日の任意の日に）、ＲＴＣＡは、それの現在のバリディティ知識を基にして（例えば、ＣＡの最後のＣＲＬを基にして）かついかなる依頼者の要求とも独立に、それのＣＡの顕著な各証明書を処理し、その証明書の状態を述べている告知にデジタル署名する。したがって、結果は、その証明書の次の更新を示す時間成分を含んでいる。ＲＴＣの期間がＣＡを発行したＣＲＬに依頼するならば、更新時間は次のＣＲＬの更新時間のことがある。時間成分は処理に用いられるＣＲＬの発行時刻を示すこともある。したがって、要するに、ＲＴＣＡは所与の時間間隔Ｔ（例えば、最後のＣＲＬの日付から‐またはそれに十分近い日付から‐次のＣＲＬの日付まで‐またはそれに十分近い日付まで、いずれの場合にも必要な全ての情報を処理することから十分な時間を取れるように）の間の各証明書の状態を示すデジタル署名を予め計算する。そのような先行する計算は証明書についてのいかなる依頼者要求とも独立して行われる。たしかに、ＲＴＣＡは、その時間間隔中の証明書状態についてのいかなる照会が行われるよりも前に、またはその時間間隔そのものよりも前にそのような署名された証明書告知の全てを予め計算する。特に、ＲＴＣＡは時間間隔Ｔが始まる１分前に時間間隔Ｔについてのそれの署名された告知の全てを予め計算することがある。そうすることによりＣＲＬ（それが使用されている場合）と「同期させられる」ようになっていないという事実は余り重大ではない。ＣＲＬ自体はリアルタイムではなく、証明書無効についての情報およびたしかに、証明書が無効にされたという理由そのものはかなり長い時間をもっと要することがある。例えば、ユーザは彼の秘密鍵が危険にさらされたことを理解でき、したがって、その事実の１日後に彼自身の証明書を無効にすることを求めることがある。このように、いかなる場合にも証明書は１日遅れで無効にされる。ＲＴＣＡが署名した証明書の告知は標準的なＯＣＳＰフォーマットである。すなわち、要するに、ＯＣＳＰに対するＯＣＳＰに従う応答を予め計算することが好ましいＲＴＣＡは、まだ発生されていないものを要求する。これは重要である。その理由は、ＯＣＳＰソフトウエアが所定の場所にあり、既存の依頼者ソフトウエアのいずれも修正することなしにＲＴＣシステムを利用することが非常に便利だからである。

ＲＴＣＡが彼の予め計算したバリディティ状態の予め計算した署名を保護されていない応答側へ送る：そのような署名を予め計算した後で、ＲＴＣＡはそれを、依頼者を含めた他の者、特に応答側、が利用できるようにする（例えば、それを送って）。それらの応答者は保護する必要はない。実際にそれらはＲＴＣＡが署名したメッセージを取り扱い、それらは検出できないやり方で不正に修正されたり変更されたりすることが本質的にできない。たしかに、ＲＴＣＡはそれらをセキュリティを危うくすることなしに外部の応答者（他の機構に属する応答者）へ容易に送ることができる。ＲＴＣＡはそれの署名を応答者に差し出すことによって、その署名を応答者が適切に編成されたやり方で容易に行うことができる。例えば、それはそれの署名した証明書バリディティ状態を証明書一連番号に従って順序付けて、またはアレイで、提示でき、または署名された各データ片が同じ長さまたは適切に閉じられた長さを確実に有するようにする、等である。関連する全ての予め計算された応答が確実に受けられるようにするために、ＲＴＣＡはそれの応答全部（例えば、同じ時間間隔およびＣＡに関連するもの全て）に署名し、日付をつけることができる。

また、ＲＴＣＡはそれの応答者にそれ自身のＲＴＣＡ証明書を送ることが好ましい。このトランザクションはあらゆる更新で起きる必要はない。特に最初にのみ実行できる。

ＲＴＣＡが予め計算した署名を応答者が保存する：応答者はＲＴＣＡの予め計算された署名を十分な時間保存する。それらの署名が所与の時間間隔Ｔに関連するものとすると、かれらはそれらを少なくともＴの終りまで保存することが好ましい。また、応答者（特にＲＴＣＡと同じ機構に属するもの）は順向とすることができ、適切なＲＴＣＡ署名を正しく時間通りに受けたことを調べることが好ましい。例えば、応答者は、
（１）時間間隔Ｔについての予め計算された応答がＴの初めに（またはＴに関連する他の適切な時間）に受けられたことを検証する、
（２）受けられたＲＴＣＡ署名を検証する（およびおそらく適切なＲＴＣＡ証明書も）、
（３）それが全ての署名を受けたかどうかを検証する（例えば、予測された署名の数より少ない、最後のトランザクションにおけるより少ない署名、等）、
（４）それが以前に告知された無効にされた証明書についてのＲＴＣＡが署名したバリディティ告知を受けたかどうかを検証する、等
ができる。何等かの問題が検出されると、それはＲＴＣＡまたはその他の適切なエンティティに知らせることがある。

依頼者がバリディティ状態情報を応答者に照会する：依頼者は証明書のバリディティ状態を応答者に尋ねる。それらはそれらの要求に対するＯＣＳＰフォーマットを用いてそれを行う。

応答者は予め計算した応答で照会に応答する：所与の証明書について照会されると、応答者はその証明書についてＲＴＣＡが予め計算した応答をメモリからフェッチし、それを戻す。

応答者は予め計算した応答に署名したＲＴＣＡに適切な証明書を送ることもする。

依頼者は予め計算した応答（およびＲＴＣＡ締め）を検証する：依存者は受けた応答を処理して対象とする証明書のバリディティ状態を確認する。その応答がＯＣＳＰフォーマットであるならば、それらはその処理のためにＯＣＳＰソフトウエアを使用することが好ましい。またそれらは適切なＲＴＣＡ証明書を検証することも好ましい。

この出願を通じて、証明書は階層的な証明書とすることができ、かつＣＡ証明書とＲＴＣＡ証明書との現在のバリディティの証明を加え、必要があれば何時でも検証できることが理解される。

図６はＲＴＣシステムを示す。

ＲＴＣシステムの諸利点：
ＲＴＣＡはＣＡの現在の証明書の全てに対してデジタル署名されたバリディティ告知（証明、その告知は偽造できないので）を定期的に発生し、その後でそれらを任意の対象とする応答者に分配する。（各証明は、ＲＴＣＡ専用鍵により署名された、統語的に正しいＯＣＳＰ応答として構成することが好ましい）。依頼者が証明書の状態について照会する、ＲＴＣ応答者はそれが受けた対応する予め発生された応答を戻すことができる。依頼者はＲＴＣＡの署名を検証できる。（また、ＲＴＣＡの証明書を検証して、所与のＣＡに対する真正なＲＴＣ権限機関を確実に取り扱えることができるようにする。）
利点１：計算：
デジタル署名は計算集約操作である。しかし、ＲＴＣシステムはこの困難を単一のサーバ（エンティティ）、ＲＴＣＡ、に集中する。したがって、この１つのエンティティに、求められている全てのデジタル署名を取り扱うのに十分強力なコンピュータを装備することは非常に容易で、比較的安い費用で装備できる。対照的に、ＲＴＣ応答者は些細な計算のみを実行する。それらは本質的には、（１）ＲＴＣＡ署名を保存し、（２）依頼者の照会に応じてフェッチ‐送り操作だけを行う。したがって、それらは非常に安いハードウェアで実現できる。その結果、ＲＴＣの総費用をＯＣＳＰのそれよりも十分に低くできる！同時に、応答時間ははるかに短い。たしかに、非常に安価なＲＴＣ応答者が予め計算されたＲＴＣＡ応答をフェッチして送るための時間は、依頼者の照会に応じてデジタル署名を実行せねばならないＯＣＳＰ応答者が要する時間と比べて無視できる。

利点２：通信：
このＲＴＣシステムでは、応答者は些細なハードウェアを使用でき、かつ安全である必要はない。したがって、ＲＴＣ応答者は確かに非常に安く、膨大な数で配置できる。すなわち、ＲＴＣシステムを何時でも分布実現できる。したがって、短い時間内に無数のバリディティ照会が生じたとしても、この負荷は多数のＲＴＣ応答者の間に常に分散できて、出費の増大を招くことなしに混雑やサービスの慇懃な拒否が解消される。（ＲＴＣＡの作業の量は証明書の数に依存し、バリディティ‐状態紹介の数により影響されることはない。したがって、膨大なｋｚ宇野バリディティ照会が予測されたとしても単一のＲＴＣを使用できる。）
利点３：セキュリティ：
ＲＴＣシステムではＲＴＣＡのみ（他にＣＡ、それが異なる／異なって配置されているエンティティならば）を保護できる。実際に、応答者はいかなる秘密鍵も保存しない。それらはＲＴＣＡのデジタル署名を保存するだけであるが、全てのセキュリティ目的のために、ＲＴＣＡにより計算された後では完全に公開できる。対照的に、各ＯＣＳＰ応答者は秘密署名鍵を有する。それはどれがシステム全体と妥協できるかを妥協する。したがって、足すの等しく重要な場所よりも１つの場所を守ることが好ましい。

さらに、ＯＣＳＰにおけるのとは異なって、依頼者はソフトウエア攻撃を容易には行えない。実際に、ＲＴＣ応答者は依頼者の照会を秘密でない情報で処理する。実際にそれらは秘密鍵は持っておらず、予め計算したデジタル署名を保存することだけを必要とする。依頼者がそれの質問にある種のトロイの木馬を埋め込むことに成功したとしても、何も暴露できない。せいぜいＲＴＣ応答者が知っていることの全てを暴露できるだけで、それはどの証明書が有効で書の時間間隔内のどれが無効にされるかの完全で正確な記述である。そしてこれは秘密情報でないばかりか、認証局があまねく知られたがるような情報でさえある。したがって、それの証明書の１つを不正確に頼るものはいない！。

最後に、ソフトウエア攻撃はＲＴＣＡに対しては容易には行えないことに注目されたい。実際に、秘密鍵を有しているが、ＲＴＣＡはどのような信頼できない照会には応答しない。それはＣＡ（非常に信頼している源）からの入力を単に受け、データ（署名されたバリディティ報告）を定期的に出力するだけである。したがって、トロイの木馬を送り込む性能はＲＴＣシステムでは失われている！いいかえると、単一の金庫がＲＴＣシステムで十分であるかもしれないばかりでなく、この金庫にはいかなる「窓」もない。

利点４：信頼の流れ：
それらの利点に加えて、ＯＣＳＰを介したＲＴＣ(RTC-over-OCSP)手法によって、多数の機構を含んでいる多様なＰＫＩ配置に大きな融通性を持たせることができる。以下の線図はＲＴＣ‐ｏｖｅｒ‐ＯＣＳＰがクロスＣＡ環境でどのようにして配置されるかを示すものである。

図７は機構＃２からの応答者が機構＃１からの応答を、機構＃１から機構＃２の応答者へいかなる信頼も転送する必要なしに、中継できるか（ＯＣＳＰに従順であることが好ましい）を示す。ＲＴＣ応答者は簡単で、信頼されていない情報中継であるので、それらは、システム全体のセキュリティを減ずることなく広く分布できかつ反映できる。依頼者は、機構＃１の証明書のバリディティについて機構２（機構２Ｂ）の応答者に照会する。それが得る（ＯＣＳＰに従順であることが好ましい）応答は、それが機構＃１のＲＴＣＡ（ＲＴＣＡ１）によりデジタル署名されているので、それは確信することに注目されたい。さらに、右の機構（これはそれ自身の証明書が依然として有効である事を知るために最も良く配置され、かつそれは誤りを犯さないことに最大の関心が有る）からの直接デジタル署名は、ＲＴＣＡ１が確かに機構１の適切なＲＴＣ権限機関であることを保証する依頼者がＲＴＣＡ１の証明書（ＣＡ１により署名されていることが好ましい）も獲得するという事実により確認することが好ましい。

要するに、機構＃１は機構＃２自身の証明書のバリディティ状態に対する管理のいかなる量も放棄することなく、機構＃２の応答者が機構＃１の証明書のバリディティの有力な証明を提供できるようにする。名ＲＴＣシステムでは信頼が１つの機構から他方へ流れ、しかもそれに伴うセキュリティや管理の喪失はない。

利点５：セキュアな異種性確保
図７は極端な場合を示し、ここでは応答者が強化された信頼点ではなくて透明なネットワーク下部構造として取り扱われている。それはＲＴＣの極端な場合が、多数の源からの証明書の状態についての照会を処理できる応答者の雑多な群の安全な構造を、どのようにして可能にしているかを示す。これはインターネットのＤＮＳ下部構造により提供されるサービス群に類似し、照会の有効な応答を発見およびキャッシュするために明らかに共通動作する名称サーバの異種集合を許す。

この異種性は従来のＯＣＳＰに優るＲＴＣシステムの大きな利点である。それにより、種々の機構からの依頼者が他の機構からの証明書を安全で、信頼できる、効率的なやり方で相互バリデイトできるように、多種多様な機構が共通に動作できるようにされる。

リアルタイム証明書（ＲＴＣ）は費用効果がよく、安全で、大規模化が可能で、全体的に効率が高いバリデーションシステムである。ＲＴＣは（１）オープン証明書状態プロトコル（ＯＣＳＰ）の代替物を提供でき、かつ（２）ＯＣＳＰ内で動作してＯＣＳＰを強化できる。ＲＴＣは、実際に、ＯＣＳＰ規格との互換性を維持する選択を行った場合でも、質的に優れたセキュリティおよび大規模化を提供するように、ＯＣＳＰよりも大きな利点を提供する。

ＲＴＣ最適化：
二当事者対三当事者証明書バリデーション：
Ｕを証明書Ｃｕを持つ関係者とする。関係者Ｖとのトランザクションの一部として、ＵはＣｕをＶへ送ることができ（Ｖがそれを既に持っていなければ）、付加タスク（Ｕに属しているＣｕにおいて証明される公開検証鍵に対してデジタル署名を示す、またはＵに属しているＣｕにおいて証明される公開暗号化鍵を用いてＶにより暗号化されるランダムな問い掛けを解読することにより特定されるなど）をおそらく実行する。トランザクションを安全にするために、ＶはＣｕの現在のバリディティを確認し、ＲＴＣ応答者にバリディティ照会を行うかもしれない。応答者はこの照会に応答してほとんどの現在のＲＴＣＡが署名したＣｕについての告知をフェッチしかつ戻す。しかし、ＲＴＣ応答者に照会すると三者を、他の場合には二者であるトランザクションにして、所望のＵ‐Ｖトランザクションの時間を長くする。

それの予測可能な時間間隔のおかげで、ＲＴＣは大幅に助けることができる。すなわち、関係者Ｕは各時間間隔Ｔの初め（またはいずれにしてもその最中）に、ＣｕがＴの間中有効であるというＲＴＣＡが署名した告知Ｄｕを受けることがある。Ｕは彼に対する照会に応じて（または通常の依頼者照会を行うことにより）Ｄｕを受けることができ、またはＤｕを押す（例えば、更新ごとにＲＴＣ応答者によりまたはＲＴＣＡによって）ことができる。いずれの場合にも、トランザクションに伴う他のステップまたは他のタスクの全てに加えて、期間Ｔ中のＶでの処理で、ＵはＤｕをＶへ送ることができる。したがって、Ｕ‐Ｖトランザクションはスピードが大幅に高くなる。その理由はＶがＵの証明書の現在のバリディティを確かめるためにＶは三者を呼び出す必要はないからである。

ある意味で、Ｄｕを含む、「全体の時間」を短縮できないかも知れず、Ｕ‐Ｖトランザクションはそうなるであろう。全体の時間を短くすることなしにＵ‐Ｖトランザクションのみを速くすることは依然として全く貴重である。実際に、ＲＴＣＡ告知が真夜中に計算され、全日をそれの時間間隔として指定する。その後で、ＵはＤｕを日の早いうち（実際の圧力が存在しない時）に受け、その後で、時間短縮が重要である作業時間中に行われる時間に敏感なＵ‐Ｖトランザクション中にそれをＶへ送ることができる。ＤＵを獲得した後で、いくつかの（例えば、１００）の関係者を処理する日の１日中Ｕがそれを送るとすると、効率が一層高くなる。このようにして、例えば、単一の関係者照会（Ｕ自身のそれ、おそらく緩和された時間に行われる）が１００の依頼者照会の置き換えに成功する（おそらく圧力時に）。

この最適化は関係者Ｖにより達成することもできることに注目されたい。すなわち、関係者Ｕの証明書Ｄｕのバリディティについての照会への回答としてＲＴＣ応答者からの応答Ｄｕを得た後で、関係者ＶはＵに与えることができ、または他者がＤｕを使用できるようにする。

この最適化は好適なＯＣＳＰに従うＲＴＣＡの実現にも適用される。実際には、我々は類似の最適化を従来のＯＣＳＰ実現にも適用することを示唆する。すなわち、ユーザは彼自身の証明書についてのＯＣＳＰを求めて獲得し、その後でこのＯＣＳＰ応答を彼のトランザクションの部分としてトランザクションの他の関係者へ適切な時間間隔中に送る。あるいは、関係者Ｕの証明書Ｃｕのバリディティについて依頼者が最初に照会すると、ＯＣＳＰ応答者はそれの応答Ｒｕを計算し、それを照会している依頼者へ戻酢が、またそれをＵへ送って、Ｕがそれをキャッシュできるようにし、少なくともしばらくの間、Ｃｕを基にしてそれのトランザクションの部分として送ることができる。

証明書が支援したバリデーション：
ＲＴＣシステムは個々の証明書で見出されるデータを用いて実現でき、それにより付加証明書と応答の長さとの少なくとも一方を省略できる。前に見たように、ＣＡは、ＲＴＣＡ自身の証明書のバリディティについての許可応答を与えることを所与のＲＴＣＡができるようにするＲＴＣＡ証明書を発生できる。そのようなＲＴＣＡ証明書は、ＲＴＣＡが署名した応答を検証するために使用せねばならない公開鍵を理想的に指定する。しかし、ＣＡはこのＲＴＣＡ公開鍵をそれ自身の証明書内に埋め込むことができる。すなわち、ＣＡは（適切なフォーマット、ＯＩＤ等で）Ｃｕのバリディティについてのデジタル署名された応答を検証するために使用すべき公開鍵ＰＫも証明書Ｃｕ内に含むことができる。このようにして、依頼者は別のＲＴＣＡ証明書を受ける必要はない。Ｃｕのバリディティの最後の証明についてＲＴＣに照会すると、それはＲＴＣＡが署名した応答のみをちょうど受けることがある（それがそう照会したので）。実際に、Ｃｕは、Ｃｕのバリディティの証明をを検証するために依頼者が者が使用できる公開検証鍵をＣｕ自身内で指定する。これは伝送を大きく節約し（ＲＴＣが応答者が別々のＲＴＣＡ証明書を送る必要がないかもしれず、それはＲＴＣＡ応答よりもはるかに長いことがある）、および保存を大きく節約できる（Ｃｕに依頼することの将来の苦情に対する保護として、依頼者がＲＴＣＡ証明書をＲＴＣＡ応答と一緒に保存する必要がないことがあるので）。

同様に、証明書Ｃｕはそれ自身の時間間隔を指定できる。この場合には、ＲＴＣＡ応答は間隔Ｔの初めと終わりを指定する必要はないことがある。実際に、Ｔの初めのみ（または他のより簡単なこと）はＴを束縛することがある。例えば、Ｃｕが毎日の日付を指定するものとすると、所与の日内の任意の時刻が、応答が照会する全部の日を指定するのに十分である。あるいは、（例えば、ＣＡの一般的な製作から）、証明書が前日より成るバリディティ間隔を持つことが明らかであるならば、この情報を証明書内で指定する必要はなく、しかもＲＴＣＡ応答適用を同じように節約する。

別々の無効化：
所与の証明書Ｃｕについてのバリディティまたは一時停止のＲＴＣ証明はそれが照会する時間間隔を指定すべきであるが、無効の証明はいかなる時間間隔も指定する必要はない。時間の１つの点（例えば、実際の無効時刻）を指定するだけで十分である。バリディティおよび一時停止とは異なって、実際に、無効は無効にできないプロセスである。したがって、１つの無効時刻ｒｔは無効にされた証明書を明らかにするのに十分である。そして、ｒｔは任意の時間間隔Ｔの初めにする必要はない（例えば、それを「Ｔの中間の」任意の時刻にできる）。したがって、永久的な無効の場合には、ＲＴＣＡはＣの無効証明を全ての更新日（例えば、Ｄ１、Ｄ２等）に送る必要はない。原則として、無効証明は１回だけ（または冗長にするために数回）送ることができ、その後でＲＴＣ応答者によりキャッシュでき、その後でＣについての依頼者照会が行われる時は常に戻される。

ＲＴＣＡは証明書Ｃが無効にされたら、例えば、ＲＴＣＡがＣにバリディティの証明を既に生じてＲＴＣ応答者へ送った時間間隔Ｔの中間に、ただちに知らされることがあることに注目されたい。もちろん、次の更新までに、そのようなバリディティ証明はＣについて計算されない。しかし、しばらくの間（すなわち、Ｔが終わるまで）はバリディティの不正確な証明はそこから出される。したがって、良いカウンタ測定が無効の証明がバリディティの証明より先行することより成る。すなわち、ある時間間隔Ｔの間のｃについてのバリディティの証明と、Ｃについての無効証明（時刻ｔは何時でも）を見る正直な依頼者は、Ｃを無効にされたと見なすべきである（時刻ｔの後）。しかし、いくつかの依頼者はそのような無効証明を決して見なかったことがあり、したがって、ＣはＴが終わるまでは依然として有効であるといくらか考えるかもしれない。先に見たように、そのような問題は、従来のＯＣＳＰにおいてさえも、Ｃが無効であるという知らせが応答者に到達するのにある時間がかかり、Ｃを無効にすべきであることを実現するのにより長い時間を要することがある、という意味で多少避けることができない。けれども、それらの問題は、Ｃが無効にされたことを知る（例えば、次のＣＲＬ更新を待つことなくＣＡから直接）と、ＲＴＣＡがただちに（予定された日Ｄ１、Ｄ２、等またはＤ１’、Ｄ２’等）Ｃの無効の証明を計算してそれを全てのＲＴＣ応答者へ送ることにより減少できる。その後で、適切に機能するＲＴＣ応答者の全てはＣのバリディティのいかなる証明もメモリから消去し、それを新たに受けた無効証明と置き換える。このようにして、その時刻から。彼等はＣのバリディティについての正確な証明を依頼者に提供する。

システムの一般性：
ＣＡ／ＲＴＣＡ／応答者／関係者／ユーザは任意のエンティティ（例えば、人、機構、サーバ、装置、コンピュータプログラム、コンピュータファイル）またはエンティティの集合とすることができる。

証明書は全ての種類の証明書、特に階層的証明および階層なし証明を含むことを理解すべきである（米国特許第５４２０９２７号参照、参照することにより含まれる）。バリディティ状態およびバリディティ状態の証明は階層的証明のバリディティ状態およびバリディティ状態の証明（例えば、一連の証明中の全ての証明のバリディティ状態およびバリディティ状態の証明）を含むことがある。証明書Ｃのバリディティを検証することはＣを発行したＣＡに対するＣＡ証明のバリディティと、Ｃのバリディティ状態についての署名された応答を与えるＲＴＣＡについてのＲＴＣＡのバリディティを検証することを含むことがある。

従来は証明書は所与の鍵を所与のユーザに結び付けるデジタル署名されたドキュメントであるが、米国特許第５６６４１６号（参照することにより含まれる）によって、証明書は全ての種類のデジタル署名されたドキュメントを含むべきである。例えば、ＣＡとして機能する売り主が価格表にデジタル署名することにより（おそらく日付情報と一緒に）その価格表を検証できる。そのような証明書のバリディティ状態は非常に重大である。例えば、売主は価格表の現在のバリディティを証明することを望む（およびそれの現在のばでの証明が証明されなければ、価格票の中の所与の価格を尊重することを拒絶する）。そうすると、顧客は価格表ドキュメントの現在のバリディティを確認することを望む。特に、ＲＴＣシステムはウエブページの現在のバリディティを立証するために理想的なものである（それの大規模化可能性およびオフライン処理のために）。たしかに、ＲＴＣＡが発生した現在のバリディティの証明をページ自体の次に（または一緒に）保存できる。

一片のデータＤを（関係者Ｘへ）送ることはＤを使用できる（またはＸにＤを受けさせる）ようにすることを含むものと解すべきである。

リアルタイムバリデーションによる三要素認証：
以下に説明するのは、関係者において連結下部構造なしで実行されるリアルタイムバリデーションおよび無効化による効率的な三要素認証である。これはドアなどの物理アクセス用途、またはファイルやアプリケーションのアクセスなどの論理用途のために機能できる。物理アクセスのシナリオを以下に説明する。その他の応用は当業者にとってはこのモデルから容易に一般化できる。

例１６：
１．ユーザは無線装置（物理トークン）に保存されている証明書を有する。このトークンはデジタル署名と専用鍵を安全に保存できる性能を持つことが好ましい。また、トークンは長距離（ＷＡＮ）接続法（ＧＰＲＳ、ＳＭＳ、ページャーＣＤＭＡ、ＧＳＭ等など）と、短距離（ＰＡＮ）接続法（ブルートゥース(Bluetooth)、ＩＲ、ＲＦ等）を有する。トークンは日の付加認証要素（ＰＩＮ用のキーパッドまたはバイオメトリック読取器など）も有する。この例はトークンがブルーツゥース携帯電話であると仮定している；
２．ドアは標準ＰＫＩ操作を実行できる小型ＣＰＵを有する制御パネルと、物理トークンと会話するための短距離（ＰＡＮ）接続法とを有する。この例は我々の標準デモドアに類似するブルーツゥースが可能にするコンピュータを仮定している；
３．ユーザはＰＩＮ番号を携帯電話に入力すること（または、バイオメトリック読取器を利用できるならば、彼自身のバイオメトリック情報を入力する）を助言される。この助言は、ユーザがドアを通ろうと試みる最初の時に、数時間ごとに、ランダムに、特殊なＳＭＳメッセージを受けた時に、１日に１回行うことができる。ＰＩＮ（またはバイオメトリック）は認証の第２の要素として機能し、物理アクセス用途に使用するために電話の「ロックを解除する」；
４．ユーザがドアの範囲内（ブルーツゥースの場合には３０フィート）に来ると、電話およびドアは相互に認識して最初の心証とバリデーション動作を開始する；
４．１（オプション）ドアはドアの証明書をブルーツゥースを介して電話へ送ることによりドアは自身を電話に対して証明書する。電話は証明書を検査し、我々の標準法のいずれかを用いてドアをバリディイトする（電話へ定期的に送られるドアのｍｉｎ‐ＣＲＬが良いやり方である）。これは「悪党読み手」の問題を解決し、電話が任意の情報を明らかにする前に真正な読み手であることを確かめる；
４．２ 電話はユーザのバイオメトリック詳細を含んでいるユーザ証明書を送る。電話はＲＴＣ証明の現在のバリディティを示すために、ＲＴＣ証明（バリデーション‐トークン‐すなわち、バリディティの２０バイト証明‐または分布されたＯＣＳＰ証明）も送る。その証明はＷＡＮを介して、１９９７年９月９日に発行された「証明書無効化システム(Certificate Revocation System)」という名称の米国特許第５６６６４１６号に記述されているものなどの、正常なCoresStreetのやり方で既に受けられていた；
４．３ ドアはユーザの証明書を正常なＲＴＣのやり方で認証およびバリデートする。ドアは現在範囲内（多数の被用者がドアの付近に居ることがある）にある多数の（または全ても）電話に対してそれを行うことができる；
５．ユーザがドアに達するまでに、以前のステップは終了している。ユーザは彼女の指（またはその他のバイオメトリック）を、ドアにまたはドアの近く（多分実際のドアノブ）に設置されている読取器で走査する。ドアはバイオメトリック詳細を、その範囲内のバリデートされた全ての証明書に保存されているデータと照合する。バイオメトリックが一致するとドアは開く。さもなければドアは閉じたままである。

これは下記のような利点を有する：
１強力な認証（この例では三要素、もっと多くも可能である）；
２．ユーザに対して明らかである（ドアのところまで歩行してそれを開くだけ、カードは不要で、ＰＩＮ番号を記憶することもない）；
３．リアルタイム無効化およびバリデーション；
４．どのドアにも接続下部構造がない‐これを３０００フィートまたは大洋の真ん中で行う；
５．標準ハードウェア部品および標準ソフトウエア部品で構成できる。

ステップ４．１は独立関係の独立した発明である。その理由はそれが、現在知られていない解決法がない既知の問題（例えば、国防省により特定されている）を解決するからである。この技術は「無効化証明すなわちアクセスログドアが、接続されている他の人々のカード／電話へ行ったりとか、から来たりとの少なくとも一方を行う」ことにより高めることができる。

携帯コンピュータ資源を保護する：
本発明の好適な実施形態は２０バイトの偽造できない、公開「証明」を基にしている。２０バイト証明は、ハッシングと呼ばれる一方向関数を用いて暗号的に保護される。このプロセスは簡単で、暗号化を必要とせず、デジタル署名を使用しない。それらの特性は大規模配置（何億という規模）、帯域幅が制限される用途（例えば、無線用途）、オフライン・バリデーション（すなわち、ネットワーク接続を求められない）のためにこの技術を理想的なものにする。

ラップトップの盗難は、交換に要する費用、生産性の喪失、回復できない（バックアップされていない）データの喪失、貴重な／秘密データ（例えば、貴重な運用情報、顧客への提案、ｅメール、カレンダー、コンタクト、係属中の合併、新製品ＩＰ、戦略、および事業計画、金融運用結果、個人保証情報、等）、およびネットワークや下部構造の細部（例えば、ユーザ名およびパスワード、ダイヤルイン番号、ＩＰアドレス技術、ＤＮＳネーミング規約、および一次メールサーバ）の喪失をもたらす重大な問題である。

一実施形態では、本発明はリース、すなわち、指定された期間中使用するためのライセンス、を行う。そのリースの機関は構成可能なパラメータである。本発明の技術は有効な「リース」の存在を強制する。リースは２０バイトの、偽造できない、「公開トークン」、すなわち、有効なトークン、一時停止トークン、および無効トークン、である。新規なリースは自動的に受けられる。コンピュータは一時的に使用不能にでき、システム管理者またはユーザはラップトッの一時停止を解除できる。コンピュータはシステム管理者による可能な回復により永久に使用不能にできる。図８は本発明の一実施形態によるシステム操作の略図である。

装置が依然として許可されている限り、有効なリーストークンは１日に１回（時間、週等）中央権限機関により発生される。有効なリーストークンを保護されている装置に置くことは多数のことなる方法で行うことができ、それはユーザに対して完全に明らかにされる。装置が盗まれた場合には２つのことが起きる。すなわち、有効なリーストークンは発生を停止する（当日を過ぎると使用を延長する道はない）、無効トークンがネットワークへ伝わる（どの接続も装置をただちに使用不能にする）。盗まれた装置は、秒（最良の場合、プッシュ機能が存在する場合）、時間（平均的なもの、いかなるネットワーク接続が行われても直ちに）、１日（最悪の場合、接続不能）、以内でオフにされる。

このシステムはゆきずりの盗難や内部の者による盗難を防止する。装置を盗んでも意味がない。その理由はハードウェアは使用できず、ソフトウエアは使用できず、データは読出せないからである。

バリディティトークンは次のような方法により提供される。すなわち、有線ネットワーク、無線ネットワーク、ＳＭＳ無線「プッシュ」、ぺージャーシステム、赤外線ポートを介する手持ち電話／ＰＤＡ、ブルートゥース装置、ファックス・ｅメール・電話呼び出しなどの代わりのチャネルを介して受けられる手動型（例えば、「7G9L TC77 U8QL S2PS QK2Q EN9V PXXH XPUL」）。図９は盗まれたコンピュータ時系列の略図である。別の保護法は、阻止のための物理的なアンカー、回収のためおよび妨害物としての資産追跡サービス、妨害物としておよびアクセス管理のためのアクセス鍵、回収のためおよび妨害物としての追跡ソフトウエア、およびデータのみを保護するデータ暗号化、を含むものを使用できる。攻撃の恐れと結果；
ソフトウエアの除去／迂回：「管理特権」を有するならば可能であるが無効になった後は極めて困難である。選択できるＢＩＯＳ／ハードウェア対策はほぼ１００％の保護を行える、
ハードドライブの交換／改造：全てデータ喪失を安全にし、選択するＢＩＰＳ／ハードウェアはドライブの交換を阻止するために留め金で留める、
データを読出すためにハードドライブを他のマシンへ移動する：データを暗号化できる、
無効トークンの受取り阻止：リースが失効するまでのみラップトップの操作を延長する（最悪の場合）。

本発明のその他の実施形態は、この明細書を読んでから、またはここで開示している本発明の実施から当業者には明らかであろう。明細書および例は例示のみと考えること、本発明の真の範囲と要旨は以下の請求の範囲により示されるものであることを意図している。

本発明の一実施形態に従って、ＣＡが発行したがまだ有効期限内である証明書Ｃ₁，…，Ｃ_kのおのおのについて、そのＣＡが個々の証明書無効状態情報ＣＲＳ_iをディレクトリへどのようにして送るかを示す概略図である。 ささいなＯＣＳＰ環境における一連のトランザクションを示す概略図である。 かなりの混雑と遅延をひき起こすサーバにおける大きな「ネットワーク隘路（ボトルネック）」を示す概略図である。 種々のセキュリティドメインから送られてきた証明書有効性の照会（リクエスト）を処理する際にＯＣＳＰがどのような困難に遭遇するかを示す概略図である。 本発明の一実施形態による、種々のセキュリティドメインから出た証明書有効性の照会を処理を示す概略図である。 本発明の一実施形態によるＲＴＣシステムを示す概略図である。 本発明の一実施形態によるＯＣＳＰを介したＲＴＣ(RTC-over-OCSP)がクロスＣＡ環境内にどのようにして配置されるかを示す概略図である。 本発明の一実施形態によるシステム動作の略図である。 盗まれたコンピュータのタイムライン（時間図）を示す概略図である。

Claims (21)

1. 現在の時刻を決定する手段を有する少なくとも１つの非接続のドアＤへの少なくとも１人のユーザＵのアクセスをエンティティＡが管理する方法であって、
   一連の日付の各時間間隔ｄに対して、ユーザＵが時間間隔ｄ中にドアＤをアクセスできることを示すデジタル署名ＳＩＧＵＤｄをＡが発生するステップと、
   Ｄを通ることができるようにするために、時間間隔ｄ中にＵにＳＩＧＵＤｄを受け付けさせてドアＤに提示するステップと、
   ＵがＳＩＧＵＤｄをドアＤに提示するステップと、
   （ｉ）ＳＩＧＵＤｄが、確かに、Ｕが時間間隔ｄにドアＤをアクセスできることを示すＡの署名であることと、（ｉｉ）現在の時刻が確かに時間間隔ｄ内であることと、を検証した後でＤを開かせるステップと、
   を備える方法。
2. Ｕがユーザカードを有し、Ｄが電気機械的な錠に接続されているカード読取器を有し、ＵはＳＩＧＵＤｄを彼のカードに保存することによりＳＩＧＵＤｄを受け取り、Ｄのカード読取器により彼のカードを読み取らせることによりＳＩＧＵＤｄをＤに提示する、請求項１に記載の方法。
3. Ａは、ＵがアクセスできるデータベースにＳＩＧＵＤｄを掲載することにより、時間間隔ｄ中にＳＩＧＵＤｄがＵに受け取られるようにする、請求項１に記載の方法。
4. ＳＩＧＵＤｄが公開鍵署名であり、ＤがＡの公開鍵を保存する、請求項１に記載の方法。
5. ＤがＵについての識別(identity)情報も検証する請求項１に記載の方法。
6. Ｕについての識別情報は、ＰＩＮと、Ｄの問い掛け（チャレンジ）に対する応答との少なくとも１つで構成される、請求項１に記載の方法。
7. エンティティＡと、少なくとも１つの非接続のドアＤと、ドアにアクセスするためにユーザカードを所有するユーザとを備えるアクセス管理システムにおける、所与のユーザＵがＤにアクセスすることを試みたことを、非接続のドアＤがＡに通知する方法であって、
   ＵがドアＤにアクセスすることを希望していることを示す情報ＩＵをＤがＵから受け取るステップと、
   ＤがＩＵを少なくとも一時的に保存するステップと、
   少なくとも１人の引き続くユーザＶに対して、エンティティＡに提示するためにＤがＶにＩＵをＶのカードに少なくとも一時的に保存させるステップと、
   を備える方法。
8. ＡがアクセスできるデータベースへＩＵを転送することにより、あるいはＡに情報を送信することにより、ＶがＩＵをＡへ提示する、請求項７に記載の方法。
9. ＩＵは、（ｉ）ドアＤをアクセスするためにＵに供給される情報と、（ｉｉ）ＤをアクセスするためにＵにより発生される情報と、の少なくとも１つを含む、請求項７に記載の方法。
10. ＩＵはＵにより発生されるデジタル署名を含む請求項７に記載の方法。
11. ＩＵはＵのデジタル署名を含む請求項７に記載の方法。
12. リアルタイム信用証明体であって、固定されている第１の部分と、定期的に変更される第２の部分とを含み、前記第２の部分は前記リアルタイム信用証明体が現在通用のものであることの証明を与えるリアルタイム信用証明体を調べることと、
    前記第１の部分に対してある操作を実行して、その結果を前記第２の部分と比較することにより、リアルタイム信用証明体の有効性を検証することと、
    リアルタイム信用証明体が有効であると検証された場合のみに物理アクセスを行えるようにすることと、
    を備える物理アクセスを管理する方法。
13. 前記第１の部分が権限機関によりデジタル署名される請求項１２に記載の方法。
14. 権限機関が前記第２の部分を提供する請求項１３に記載の方法。
15. 前記第２の部分が前記権限機関以外のエンティティにより提供される請求項１４に記載の方法。
16. 前記リアルタイム信用証明体がスマートカード上に設けられる請求項１２に記載の方法。
17. ユーザは、前記リアルタイム信用証明体の前記第２の部分を第１の場所で取得する請求項１２に記載の方法。
18. 前記ユーザは、前記第１の場所とは異なり離れている第２の場所にアクセスすることを許される、請求項１７に記載の方法。
19. 前記リアルタイム信用証明体の前記第１の部分の少なくとも一部が、前記リアルタイム信用証明体の前記第２の部分の一部に複数回適用される一方向ハッシュを表す、請求項１２に記載の方法。
20. 前記複数回は、前記リアルタイム信用証明体の前記第１の部分が発行されてから経過した時間の量に対応する請求項１９に記載の方法。
21. 物理アクセスの管理は、ドアを通るアクセスを管理することを含む、請求項１２に記載の方法。

Images