JP2013118706A - 無線周波識別（ｒｆｉｄ）認証およびそのための鍵配信システム - Google Patents

Abstract

【課題】無線周波識別（ＲＦＩＤ）認証およびそのための鍵配信システムの提供。
【解決手段】楕円曲線暗号方式（ＥＣＣ）を用いて、ＲＳＡなどの従来の公開鍵の実施形態と比較して署名サイズおよび読み取り／書き込み時間を減らすＲＦＩＤ認証システムを実現する。署名サイズを減らすのにＥＣＤＳＡまたはＥＣＰＶＳを用いることができる。ＥＣＰＶＳは、ＲＦＩＤタグにおける機密製品の識別情報を含む部分を隠すために用いることが可能である。その結果、より小さいタグを用いることができる。あるいは、製造過程やサプライチェーンにおける様々な段階で、複数の署名を書き込むことができる。鍵管理システムが、検証鍵を配布するのに用いられる。また、例えばサプライチェーンにおいて、ＲＦＩＤタグに複数の署名を加えるための集約署名方式を実現する。
【選択図】図１

Description

本発明は、無線周波識別（ＲＦＩＤ）タグおよびＲＦＩＤ認証システムに関するもので
あり、特に、ＲＦＩＤタグの署名時および認証時における有用性に関するものである。

従来、在庫品や販売用商品などの物品は、その物品の追跡、識別および／または監視が
可能となるように、それぞれ対応する識別子がつけられている。昨今、識別子を付与する
ための技術として、バーコードは、無線周波識別（ＲＦＩＤ）技術に置き換えられつつあ
る。ＲＦＩＤには、利用者や機械がバーコードタグを見つけて独特の方法で読み取る必要
がなく、自動識別システムを実現するという利点がある。

無線周波識別は、ＲＦＩＤタグ、または、ＲＦＩＤ中継器と通常称される装置を用いて
のデータの保存およびデータの遠隔からの取り出しに依存している。ＲＦＩＤタグは、電
波を使った識別を目的として、製品や動物などの生物に、取り付けるまたは組み込むこと
ができるものである。ＲＦＩＤタグにはシリコンチップおよびアンテナを含むチップベー
スのものがある。そして、ＲＦＩＤタグには、パッシブタイプとアクティブタイプとがあ
る。

パッシブタイプのＲＦＩＤタグは、内部に電源を必要としない。入ってくる無線信号に
よってアンテナで生じた比較的小さな電流により、タグの中の回路には、電源を入れて応
答を送信するのに十分な電力が供給される。しばしば、パッシブタイプのタグは、リーダ
からの搬送信号を後方散乱させて信号を送る。したがって、アンテナは入ってくる信号か
ら電力を集め、かつ、外に向かう後方散乱信号を発信するように設計されている。搭載電
源を必要としないので、パッシブタイプのＲＦＩＤタグを、より小さなサイズで実現する
ことができ、よりコストパフォーマンスが高い。

アクティブタイプのＲＦＩＤタグは、タグ内の、外へ出て行く信号を発生させるどの回
路にも電力を供給できる電源を内蔵している。アクティブタイプのタグは、リーダとの“
セッション（session）”を行うことができるので、パッシブタイプのＲＦＩＤタグより
も信頼性が高いことがわかっている。アクティブタイプＲＦＩＤタグは搭載電源を持って
いるので、高出力信号を発信できる。そのため、水中や比較的長距離などの、ＲＦ信号の
伝送が難しい領域においては、アクティブタイプのＲＦＩＤタグの効果は大きい。また、
搭載電源にはより広い空間が必要となるので、アクティブタイプＲＦＩＤタグは、通常、
パッシブタイプＲＦＩＤタグよりもサイズが大きく、高価である。

ＲＦＩＤシステムは一般的にタグ、タグリーダ、および、サポートインフラ（supporti
ng infrastructure）を備えている。ＲＦＩＤシステムの目的は、ＲＦＩＤリーダに読み
取られて処理されるデータを、携帯機器（タグ）によって伝送可能とすることにある。そ
の処理量およびデータの性質はその用途により大きく左右される。例えば、タグにより伝
送される情報は、タグが付けられた対象物に関する識別情報、場所情報、または、仕様を
提供するものであってもよい。例えば、在庫追跡といった典型的な用途において、ＲＦＩ
Ｄシステムでは、追跡されるべき対象物に小さく、安価なタグを取り付けて用いる。その
タグは、ユニークなコード（例えば、製品コードなど）が与えられたメモリを備えたトラ
ンスポンダ（transponder）を含む。信号は、ＲＦＩＤタグを作動させるリーダから発信
される。その結果、リーダが、データを読み取ったり、データをタグに書き込んだりでき
る。ＲＦＩＤタグが、上記信号の発信によってできた電磁ゾーンを通るときに、タグはリ
ーダからの作動信号を検出する。そして、リーダは、タグのメモリ中の符号化されたデー
タをデコードし、該データは、特定の利用目的のため、サポートインフラに送られる。

ＲＦＩＤ技術は、在庫や商品の追跡に必要な労力を減らすためだけでなく、偽造品や欠
陥品の存在など、機密事項の問題に対抗するための技術として普及しつつある。薬剤のサ
プライチェーン（supplychain）の安全性を進歩させて、かつ、患者の安全性を高める上
で、上記機密事項の問題は、製薬産業において重要性が一層高まってきている。現行の作
業には、サプライチェーン中にある製薬品に認証の階層を付加するステップ（adding a l
ayer ofauthentication）が含まれる。この作業では、特に、以下の白書に述べられてい
るＲＦＩＤシステムと組み合わせた公開鍵暗号基盤が用いられる。上記白書とは、“ＲＦ
ＩＤと公開鍵暗号基盤（ＰＫＩ）技術を用いた薬剤サプライチェーンの保護（Securing t
hePharmaceutical Supply Chain with RFID and Public-Key Infrastructure (PKI) Tec
hnologies）”（JosephPearson著, Texas Instruments Radio Frequency Identificatio
n (TI-RFID^TM)Systems, RFIDPH01, 2005年6月）と題された白書である。

上記白書に記述されたようなＲＦＩＤ認証システムでは、サプライチェーンの１または
複数の段階でタグを認証することが可能であり、サプライチェーン全体の整合性が確保さ
れる。

上記を実施するのためには、例えば、１０２４ビットＲＳＡ（Rivest-Shamir-Adleman
）デジタル署名などの比較的サイズの大きな署名を十分に格納できるＲＦＩＤタグが必要
となる。このため、コストが非常に高くなる。その結果、ＲＳＡ署名が署名される場合、
認証用ＲＦＩＤタグは、用途に見合わない高価なタグを必要としなければ、１つの署名し
か収容できない。また、必要な署名が一つの場合であっても、比較的大きなタグが必要で
ある。

上記のような比較的サイズの大きなＲＳＡ署名を使用して、１つのタグ上で複数の署名
を使用しようとした場合、タグのサイズを大きくしなければ、実現不可能である。タグの
サイズを大きくした場合、コストはさらに増加する。

以上のことから、上記不都合を防ぐこと、または、緩和することが、以下の本発明の目
的である。

一実施形態において、無線周波識別（ＲＦＩＤ）タグに安全性を高める方法を提供する
。上記方法は、該ＲＦＩＤタグを取得するステップと、楕円曲線（ＥＣ）暗号方式を用い
て上記ＲＦＩＤタグに署名するステップとを含む。

上記方法は、ＥＣＰＶＳ署名方式、または、ＥＣＤＳＡ署名方式のどちらかを用いて提
供する。

他の実施形態において、楕円曲線暗号署名を含む無線周波識別（ＲＦＩＤ）タグを提供
する。

さらに他の実施形態において、ＲＦＩＤタグに署名する方法を提供する。上記方法は、
権限のないＲＦＩＤリーダに対して隠されるように意図された情報を含むデータセットで
あって、タグに書き込まれるべき第１のデータセットを取得するステップと、メッセージ
復元を伴う署名方式に、上記第１のデータセットを、復元可能な部分として組み込むステ
ップと、対応する検証鍵を有する秘密鍵を用いて、上記タグに署名を書き込むステップと
を含み、上記第１のデータセットは、上記検証鍵にアクセス可能な権限のあるＲＦＩＤリ
ーダによってのみ、復元が可能である。

さらに他の実施形態において、ＲＦＩＤ署名端末を提供する。上記ＲＦＩＤ署名端末は
、ＲＦＩＤタグを読み取るためのＲＦＩＤリーダと、上記ＲＦＩＤタグに署名を書き込む
ための暗号モジュールとを備え、上記暗号モジュールは、権限のないＲＦＩＤリーダに対
して隠されるように意図された情報を含む、タグに書き込まれるべき第１のデータセット
を取得し、メッセージ復元を伴う署名方式に、上記第１のデータセットを、復元可能な部
分として組み込み、そして、対応する検証鍵を有する秘密鍵を用いて、上記タグに署名を
書き込むように構成されている。上記第１のデータセットは、上記検証鍵にアクセス可能
な権限のあるＲＦＩＤリーダによってのみ復元が可能である。

さらに他の実施形態において、ＲＦＩＤタグの認証方法を提供する。上記方法は、第１
のデータセットを暗号化した要素を少なくとも１つ含む署名および平文である第２のデー
タセットを有するタグを取得するステップと、検証鍵を取得するステップと、上記第１の
データセットを取得するために、上記検証鍵を用いて少なくとも１つの要素を復号するス
テップと、上記署名を検証するために、所定の特徴に関して、上記第１のデータセットを
検査するステップとを含み、これにより、上記タグが認証される。

さらに他の実施形態において、ＲＦＩＤリーダを提供する。上記ＲＦＩＤリーダは、Ｒ
ＦＩＤタグのＥＣ暗号署名を検証するための暗号モジュールを備え、該暗号モジュールは
、第１のデータセットを暗号化した要素を少なくとも１つ含む署名および平文である第２
のデータセットを有する上記タグを取得し、検証鍵を取得し、上記第１のデータセットを
取得するために、上記検証鍵を用いて少なくとも１つの要素を復号し、上記署名を検証す
るために、所定の特徴に関して、上記第１のデータセットを検査して、これにより、上記
タグを認証するように構成されている。

さらに他の実施形態において、ＲＦＩＤ認証システムにおける複数のＲＦＩＤリーダ用
の検証鍵を管理する方法を提供する。上記方法は、上記複数のＲＦＩＤリーダのうちの１
以上のリーダのいずれが、１以上の製品タイプを認証する許可を得ているのかを示す、許
可のセットを決定するステップと、特定の製品タイプに対応付けられた各検証鍵のセット
を、上記許可のセットにしたがって作成するステップと、各ＲＦＩＤリーダに、上記検証
鍵のセットをそれぞれ配布するステップとを含む。

さらに他の実施形態において、複数のＲＦＩＤリーダを含むＲＦＩＤ認証システムのた
めの鍵管理システムを提供する。上記鍵管理システムは、上記複数のＲＦＩＤリーダのう
ち、１つ以上のいずれのＲＦＩＤリーダが、対応するＲＦＩＤタグを有する１つ以上の製
品タイプを読み取る許可を有しているかを示す、許可のセットを決定し、上記許可にした
がって、上記複数のリーダのそれぞれに、検証鍵のセットを作成し、上記各リーダに、上
記各検証鍵を配布する構成である。

さらに他の実施形態において、集約デジタル署名（aggregate digital signature）の
生成方法を提供する。上記方法は、第１の暗号鍵を用いて、第１のデータ部分を暗号化す
ることにより、第１の署名要素を生成するステップと、上記第１の署名要素と第２のデー
タ部分とから第１の中間署名要素を生成するステップと、上記第１の中間署名要素と第１
の秘密鍵とから、第２の署名要素を生成するステップと、上記第１の署名要素および上記
第２の署名要素のうちの１つを、第２の暗号鍵を用いて暗号化することにより、第３の署
名要素を生成するステップと、上記第３の署名要素と上記第２のデータ部分とから第２の
中間署名要素を生成するステップと、上記第２の中間署名要素と第２の秘密鍵とから、第
４の署名要素を生成するステップと、上記第１の署名要素および上記第２の署名要素のう
ちのもう一方と上記第３の署名要素と上記第４の署名要素とを、上記デジタル署名として
出力するステップとを含む。

さらに他の実施形態において、集約デジタル署名を検証するための方法を提供する。上
記方法は、デジタル署名を取得するステップであって、該デジタル署名が、第１の他の署
名要素が第１のデータ部分を暗号化する他の署名要素であって、上記少なくとも１つの他
の署名要素をそれぞれの暗号鍵を用いて暗号化する第１の署名要素と、上記第１の署名要
素および上記少なくとも１つの他の署名要素それぞれのうちの一方とそれぞれの秘密鍵と
から各々生成されている少なくとも１つの二次的署名要素と、を有するデジタル署名を取
得するステップと、上記第１の署名要素と第２のデータ部分とを用いて第１の復号鍵を生
成し、上記第１の署名要素を復号して復元された署名要素を取得するステップと、上記復
元された署名要素を用いて、１つ以上の後続の復号鍵を生成することにより、上記少なく
とも１つの他の署名要素に対応する追加の署名要素を復元するステップと、上記少なくと
も１つの他の署名要素のうちの上記第１の署名要素から、上記第１のデータ部分の表記を
復元するステップと、上記デジタル署名を検証するための所定の特徴に関して、上記第１
のデータ部分の上記表記を検査するステップとを含む。

さらに他の実施形態において、複数の署名段階で、集約デジタル署名を生成する方法を
提供する。上記方法は、最初の署名要素対を生成するステップと、次の署名要素のセット
にて上記最初の署名要素対のうちの１つを暗号化するステップであって、上記次の署名要
素のセットは、上記最初の署名要素対のうちのもう一方と２つの新しい署名要素とを含む
セットである、該暗号化するステップと、後続の署名段階ごとに、別の先の署名要素を順
々に暗号化して追加の新しい署名要素を生成してきた先の署名要素を暗号化するステップ
とを含む。ここで、上記方法では、各段階における上記デジタル署名における署名要素の
数は、各署名段階の合計数より１つ多い。

さらに他の実施形態において、集約デジタル署名を生成する方法を提供する。上記方法
は、複数の署名端末のそれぞれによって与えられた第１の個別値から算出された第１の値
を用いて、第１の署名要素を生成するステップと、上記複数の署名端末のそれぞれによっ
て与えられた第２の個別値から算出された第２の値を用いて、第２の署名要素を生成する
ステップと、上記第１の署名要素と上記第２の署名要素とを有するデジタル署名を出力す
るステップとを含む。

さらに他の実施形態において、集約デジタル署名を検証する方法を提供する。上記方法
は、複数の署名端末のそれぞれによって与えられた第１の個別値から算出された第１の値
を用いて生成された第１の署名要素と、上記複数の署名端末のそれぞれによって与えられ
た第２の個別値から算出された第２の値を用いて生成された第２の署名要素とを有する、
デジタル署名を取得するステップと、上記複数の署名端末のそれぞれの個別公開鍵を組み
合わせて、結合公開鍵を生成するステップと、署名検証処理における少なくと１つのステ
ップにて、上記結合公開鍵を用いるステップとを含む。

さらに他の実施形態において、上述の各方法を実行する暗号処理の演算処理装置および
上述の各方法を実行するためのコンピュータが読み取り可能な記録媒体を提供する。
例えば、本願発明は以下の項目を提供する。
（項目１）
無線周波識別（ＲＦＩＤ）タグの安全性を高める方法であって、
上記ＲＦＩＤタグを取得するステップと、
楕円曲線（ＥＣ）暗号方式を用いて上記ＲＦＩＤタグに署名するステップとを含む方法。
（項目２）
上記楕円曲線暗号方式は、ＥＣＰＶ（楕円曲線Pintsov-Vanstone）署名方式であり、
上記ＲＦＩＤタグを検査するステップと、
第１の署名要素に隠されるべき第１のデータ部分が有する冗長性が、所定の量より少ない場合に、該第１のデータ部分に埋め込み（padding）を行うステップとを含む、項目１に記載の方法。
（項目３）
上記ＲＦＩＤタグの未使用のデータブロックは、上記埋め込みを提供するために用いられる、項目２に記載の方法。
（項目４）
上記第１のデータ部分は、ＲＦＩＤが付けられた製品のタイプを識別するものであり、
上記埋め込みは、上記ＲＦＩＤタグ上に存在する別のデータ部分に内在する冗長性によって提供される、項目２に記載の方法。
（項目５）
上記ＲＦＩＤタグとして、複数のＥＣ署名を収容するのに十分な大きさのものが選択される、項目１に記載の方法。
（項目６）
上記楕円曲線暗号方式は、楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）である、項目１に記載の方法。
（項目７）
署名されるメッセージは、上記ＲＦＩＤタグの通し番号と識別コードとの組み合わせである、項目６に記載の方法。
（項目８）
楕円曲線暗号署名を含む無線周波識別（ＲＦＩＤ）タグ。
（項目９）
上記楕円曲線暗号署名は、ＥＣＰＶ署名であって、
第１の署名要素に隠されるべき第１のデータ部分が有する冗長性が、所定の量より少ない場合に、該第１のデータ部分に埋め込みが行われる（padded）、項目８に記載のＲＦＩＤタグ。
（項目１０）
当該ＲＦＩＤタグの未使用のデータブロックは、上記埋め込みを提供するために用いられる、項目９に記載のＲＦＩＤタグ。
（項目１１）
上記第１のデータ部分は、ＲＦＩＤが付けられた製品のタイプを識別するものであり、
上記埋め込みは、当該ＲＦＩＤタグ上に存在する別のデータ部分に内在する冗長性によって提供される、項目９に記載のＲＦＩＤタグ。
（項目１２）
当該ＲＦＩＤタグとして、複数のＥＣ署名を収容するのに十分な大きさのものが選択される、項目８に記載のＲＦＩＤタグ。
（項目１３）
上記楕円曲線暗号署名は、楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）署名である、項目８に記載のＲＦＩＤタグ。
（項目１４）
署名されるメッセージは、当該ＲＦＩＤタグの通し番号と識別コードとの組み合わせである、項目１３に記載のＲＦＩＤタグ。
（項目１５）
当該ＲＦＩＤタグの通し番号が、上記署名が行われる前に、当該ＲＦＩＤタグに焼き付けられている（burned）、項目８に記載のＲＦＩＤタグ。
（項目１６）
ＲＦＩＤタグに署名する方法であって、
上記ＲＦＩＤタグに書き込まれるべき第１のデータセットであり、権限のないＲＦＩＤリーダに対して隠されるように意図された情報を含んだ第１のデータセットを取得するステップと、
メッセージ復元を伴う署名方式に(a signature scheme)、復元可能な部分として、上記第１のデータセットを組み込むステップと、
対応する検証鍵を有する秘密鍵を用いて、上記ＲＦＩＤタグに署名を書き込むステップ
とを含み、
上記第１のデータセットは、上記検証鍵にアクセス可能な、権限のあるＲＦＩＤリーダによってのみ、復元が可能である、ＲＦＩＤタグに署名する方法。
（項目１７）
上記第１のデータセットは、製品識別子である、項目１６に記載の方法。
（項目１８）
選択された１つまたは複数の権限のあるＲＦＩＤリーダに上記検証鍵を配布することにより、上記検証鍵へのアクセスを制御するステップを含む、項目１６に記載の方法。
（項目１９）
上記署名は、第１のデータセットを暗号化する第１の要素と、上記秘密鍵および上記第１の要素を用いて生成された第２の要素とを有しており、
当該方法は、
上記第１の要素を第３の要素の中に暗号化し、該第３の要素を用いて第４の要素を生成することにより、更新された署名を生成するステップを含み、
上記更新された署名は、上記第２の要素、上記第３の要素、および、上記第４の要素を含む、項目１６に記載の方法。
（項目２０）
先の署名要素を、次の署名要素の中に暗号化し、さらに次の署名要素を生成するために上記次の署名要素を用いることにより、さらに更新された署名を生成するステップを含む、項目１６に記載の方法。
（項目２１）
ＲＦＩＤタグを読み取るＲＦＩＤリーダと、上記ＲＦＩＤタグに署名を書き込むための暗号モジュールとを備えているＲＦＩＤ署名端末であって、
上記暗号モジュールは、
上記ＲＦＩＤタグに書き込まれるべき第１のデータセットであり、権限のないＲＦＩＤリーダに対して隠されるように意図された情報を含んだ第１のデータセットを取得し、
メッセージ復元を伴う署名方式に、復元可能な部分として、上記第１のデータセットを組み込み、
対応する検証鍵を有する秘密鍵を用いて、上記ＲＦＩＤタグに署名を書き込むように構成されており、
上記第１のデータセットは、
上記検証鍵にアクセス可能な、権限のあるＲＦＩＤリーダによってのみ、復元が可能である、ＲＦＩＤ署名端末。
（項目２２）
上記第１のデータセットは、製品識別子である、項目２１に記載のＲＦＩＤ署名端末。
（項目２３）
ＲＦＩＤタグを認証する方法であって、
第１のデータセットをその中に暗号化して、少なくとも１つの要素を含んでいる署名と、平文である第２のデータセットとを有する上記ＲＦＩＤタグを取得するステップと、
検証鍵を取得するステップと、
上記第１のデータセットを取得するために、上記検証鍵を用いて、上記少なくとも１つの要素を復号するステップと、
上記署名を検証するために、所定の特徴について、上記第１のデータセットを検査するステップとを含み、上記各ステップにより、上記ＲＦＩＤタグを認証する、方法。
（項目２４）
上記第１のデータセットは、製品識別子である、項目２３に記載の方法。
（項目２５）
ＲＦＩＤタグのＥＣ暗号署名を検証する暗号モジュールを備えているＲＦＩＤリーダで
あって、
上記暗号モジュールが、
第１のデータセットを当該署名の中に暗号化する少なくとも１つの要素を含んでいる署名と、平文である第２のデータセットとを有する上記ＲＦＩＤタグを取得し、
検証鍵を取得し、
上記第１のデータセットを取得するために、上記検証鍵を用いて、上記少なくとも１つの要素を復号し、
上記署名を検証するために、所定の特徴について、上記第１のデータセットを検査するように構成されており、該構成により、上記ＲＦＩＤタグを認証する、ＲＦＩＤリーダ。
（項目２６）
上記第１のデータセットは、製品識別子である、項目２５に記載のＲＦＩＤリーダ。
（項目２７）
ＲＦＩＤ認証システムにおける複数のＲＦＩＤリーダの検証鍵を管理する方法であって、
上記複数のＲＦＩＤリーダのうちの、１または複数のＲＦＩＤリーダのいずれが、１または複数のタイプの製品を認証する許可を有するのかを示す、許可のセットを決定するステップと、
上記複数のＲＦＩＤリーダのうちの１または複数のＲＦＩＤリーダに対して、上記許可のセットに基づいて、個々の製品タイプに対応する各検証鍵のセットを作成するステップと、
上記ＲＦＩＤリーダのそれぞれに、上記各検証鍵のセットを配布するステップとを含む
、方法。
（項目２８）
上記配布するステップは、
上記ＲＦＩＤリーダそれぞれへの専用の接続が必要とならないように、定期的に行われる、項目２７に記載の方法。
（項目２９）
１または複数の上記ＲＦＩＤリーダからの鍵更新要求を受信するステップを含み、
上記許可のセットを決定するステップは、
新しい各許可を確認する（checking for new permissions）ステップを含む、項目２７に記載の方法。
（項目３０）
新しいＲＦＩＤリーダから登録要求を受信するステップと、
上記新しいＲＦＩＤリーダのために新しい許可のセットを決定するステップとを含む、項目２７に記載の方法。
（項目３１）
新しい検証鍵に対応する証明書要求を受信するステップと、
上記新しい検証鍵の証明書を返信するステップと、
上記複数のＲＦＩＤリーダのうち、１以上のいずれのＲＦＩＤリーダが、上記証明書を受け取る権限があるのかを決定するステップと、
上記各許可を更新する（updating said permissions）ステップと、
後の更新のために上記証明書を保存するステップと含む、項目２７に記載の方法。
（項目３２）
上記検証鍵の使用を報告するレポートを受信するステップと、
上記使用に収益を関連付けるステップとを含む、項目２７に記載の方法。
（項目３３）
対応するＲＦＩＤタグに書き込まれた署名の数を示すレポートを受信するステップと、
書き込まれた上記署名の数に収益を関連付けるステップとを含む、項目２７に記載の方法。
（項目３４）
予約支払いの受領(receipt of a subscription payment)に基づいて、上記配布するステップを実施する、項目２７に記載の方法。
（項目３５）
複数のＲＦＩＤリーダを含むＲＦＩＤ認証システムのための鍵管理システムであって、
上記複数のＲＦＩＤリーダのうちの、１または複数のＲＦＩＤリーダのいずれが、対応するＲＦＩＤタグを有する１または複数の製品タイプを読み取る許可を有するのかを示す、許可のセットを決定し、
上記の各許可に基づいて、上記複数のＲＦＩＤリーダのそれぞれに対して、各検証鍵のセットを作成し、
上記各ＲＦＩＤリーダに、上記各検証鍵を配布するように構成されている鍵管理システム。
（項目３６）
上記検証鍵の証明書を発行する証明書発行エージェント、証明書サーバ、および、上記検証鍵の各々に対応する各証明書を保存するための条件付アクセスデータベースを含む、項目３５に記載の鍵管理システム。
（項目３７）
ＲＦＩＤタグの署名と上記検証鍵を用いたＲＦＩＤタグの検証とを監視する制御部を少なくとも１つ含む、項目３５に記載の鍵管理システム。
（項目３８）
上記ＲＦＩＤリーダそれぞれへの専用の接続が必要とならないように、上記配布が、予定された間隔で行われる、項目３５に記載の鍵管理システム。
（項目３９）
１または複数の上記ＲＦＩＤリーダからの鍵更新要求を受信するように構成されており、
上記許可のセットの決定には、新しい各許可の確認が含まれる、項目３５に記載の鍵管理システム。
（項目４０）
新しいＲＦＩＤリーダからの登録要求を受信し、
上記新しいＲＦＩＤリーダのために新しい許可のセットを決定するように構成されている、項目３５に記載の鍵管理システム。
（項目４１）
新しい検証鍵に対応する証明書要求を受信し、
上記新しい検証鍵の証明書を返信し、
上記複数のＲＦＩＤリーダのうち、１以上のいずれのＲＦＩＤリーダが、上記証明書を受け取る権限があるのかを決定し、
上記各許可を更新し、
後の更新のために上記証明書を保存するように構成されている、項目３５に記載の鍵管理システム。
（項目４２）
上記検証鍵の使用を報告するレポートを受信し、
上記使用に収益を関連付けるように構成されている、項目３５に記載の鍵管理システム。
（項目４３）
対応するＲＦＩＤタグに書き込まれた署名の数を示すレポートを受信し、
書き込まれた上記署名の数に収益に関連付けるように構成されている、項目３５に記載の鍵管理システム。
（項目４４）
予約支払いの受領に基づいて、上記配布を実施するように構成されている、項目３５に記載の鍵管理システム。
（項目４５）
集約デジタル署名を生成する方法であって、
第１の暗号鍵を用いて、第１のデータ部分を暗号化することにより、第１の署名要素を生成するステップと、
上記第１の署名要素および第２のデータ部分から第１の中間署名要素を生成するステップと、
上記第１の中間署名要素および第１の秘密鍵から、第２の署名要素を生成するステップと、
上記第１の署名要素および上記第２の署名要素のいずれか一方を、第２の暗号鍵を用いて暗号化することにより、第３の署名要素を生成するステップと、
上記第３の署名要素および上記第２のデータ部分から第２の中間署名要素を生成するステップと、
上記第２の中間署名要素および第２の秘密鍵から、第４の署名要素を生成するステップと、
上記第１の署名要素および上記第２の署名要素のいずれかもう一方と、上記第３の署名要素と、上記第４の署名要素とを、上記デジタル署名として出力するステップとを含む、方法。
（項目４６）
鍵導出関数を、それぞれの一時公開鍵に適用することにより、上記第１の暗号鍵と上記第２の暗号鍵を生成するステップを含む、項目４５に記載の方法。
（項目４７）
上記第１の中間要素、および、第２の中間要素は、それぞれの署名要素と上記第２のデータ部分との組み合わせをハッシュ化することにより生成される、項目４５に記載の方法。
（項目４８）
上記第２の署名要素および上記第４の署名要素のそれぞれは、それぞれの中間要素の整数表記（representations）、それぞれの長期秘密鍵、および、それぞれの一時秘密鍵を用いて生成される、項目４５に記載の方法。
（項目４９）
上記第１の署名要素および上記第２の署名要素は、上記デジタル署名の第１の表記(a first representation)を作成するための第１の署名手段によって生成され、
上記第３の署名要素および上記第４の署名要素は、上記デジタル署名の第２の表記(a second representation)を作成するための第２の署名手段によって、上記第１の表記から生成される、項目４５に記載の方法。
（項目５０）
上記署名要素は、ＥＣＰＶＳ暗号方式にしたがって生成される、項目４５に記載の方法。
（項目５１）
集約デジタル署名を検証するための方法であって、
デジタル署名が、
各暗号鍵のうちの第１の暗号鍵が第１のデータ部分を暗号化するような、それぞれの暗号鍵を用いて、少なくとも１つの他の署名要素を暗号化する第１の署名要素と、
上記第１の署名要素および上記少なくとも１つの他の署名要素それぞれのうちのいずれか一方と、それぞれの秘密鍵とから各々生成されている、少なくとも１つの二次的署名要素とを有する、
該デジタル署名を取得するステップと、
復元された署名要素を取得するために、上記第１の署名要素と第２のデータ部分とを用いて第１の復号鍵を生成し、上記第１の署名要素を復号するステップと、
１または複数の後続の復号鍵を生成することによって上記少なくとも１つの他の署名要素に対応する追加の署名要素を復元するために、上記復元された署名要素を用いるステップと、
上記少なくとも１つの他の署名要素のうちの上記第１の署名要素から、上記第１のデータ部分の表記を復元するステップと、
上記デジタル署名を検証するための所定の特徴に関して、上記第１のデータ部分の上記表記を検査するステップとを含む、方法。
（項目５２）
上記復号鍵は、
上記第１の署名要素または上記少なくとも１つの他の署名要素、および、上記第２のデータ部分から、それぞれの中間値を算出し、
上記各中間値を、各整数表記に変換し、
一時公開鍵をそれぞれ生成するために、上記各整数表記と公開データとを使用し、
上記一時公開鍵から復号鍵を生成することによって、
生成される、項目５１に記載の方法。
（項目５３）
上記中間要素は、各署名要素と上記第２のデータ部分とをハッシュ化することにより、算出される、項目５２に記載の方法。
（項目５４）
上記所定の特徴とは、冗長性である、項目５１に記載の方法。
（項目５５）
上記暗号鍵は、鍵導出関数を用いて生成される、項目５１に記載の方法。
（項目５６）
ＥＣＰＶＳ検証方式を用いる、項目５１に記載の方法。
（項目５７）
複数の署名段階で、集約デジタル署名を生成する方法であって、
最初の署名要素対を生成するステップと、
次の署名要素セット内には、上記最初の署名要素対のうちのいずれか一方と、２つの新しい署名要素とが含まれており、該次の署名要素セット内に、上記最初の署名要素対のもう一方を暗号化するステップと、
続く署名段階ごとに、さらに先の署名要素を順に暗号化する先の署名要素を暗号化して、さらに新しい署名要素を生成するステップとを含み、
各署名段階における上記デジタル署名の署名要素の数は、署名段階の合計数より１つ多い、方法。
（項目５８）
項目４５から５７までのいずれか１項に記載された方法の各ステップを暗号処理装置
に実行させるためのコンピュータ実行可能な命令を記録したコンピュータ読み取り可能な記録媒体。
（項目５９）
項目４５から５７までのいずれか１項に記載された方法に従って、集約デジタル署名を生成する暗号処理装置。
（項目６０）
集約デジタル署名を生成する方法であって、
複数の署名手段のそれぞれによって与えられた第１の個別値から算出された第１の値を用いて、第１の署名要素を生成するステップと、
上記複数の署名手段のそれぞれによって与えられた第２の個別値から算出された第２の値を用いて、第２の署名要素を生成するステップと、
上記第１の署名要素および上記第２の署名要素を有する上記デジタル署名を出力するステップとを含む、方法。
（項目６１）
上記第１の署名要素は、上記第１の値を用いて、第１のデータ部分を暗号化することによって算出されたものであり、
上記第１の値は、上記複数の署名手段のそれぞれによって生成された、個々の各暗号鍵から算出された暗号鍵であり、
上記第２の署名要素は、上記第１の署名要素および第２のデータ部分から算出された個々の第２要素を組み合わせることによって算出されたものである、項目６０に記載の方法。
（項目６２）
上記個々の各暗号鍵は、上記複数の署名手段によって算出されたそれぞれの一時鍵から算出される、項目６０に記載の方法。
（項目６３）
上記個々の第２要素は、
上記第１の署名要素と上記第２のデータ部分との組み合わせをハッシュ化することによって算出された中間署名要素から個々に計算されるものである、項目６０に記載の方法
。
（項目６４）
上記個々の第２要素は、
上記複数の署名手段それぞれの秘密値から、それぞれ算出されるものである、項目６０に記載の方法。
（項目６５）
上記第１の署名要素は、上記第１の個別値の組み合わせである上記第１の値の関数にしたがって算出されるものであり、
上記第２の署名要素は、上記第２の値と上記第１の署名要素とを用いて算出されるものであり、
上記第２の値は、上記複数の署名手段それぞれからの秘密値を組み合わせることによって算出された結合秘密鍵である、項目６０に記載の方法。
（項目６６）
上記第１の個別値は、
上記複数の署名手段それぞれによって生成された各一時秘密鍵を用いて算出される、請
求項６５に記載の方法。
（項目６７）
上記第２の署名要素は、署名されたメッセージの表記を用いて算出される、項目６５に記載の方法。
（項目６８）
上記表記は、上記メッセージのハッシュ値である、項目６７に記載の方法。
（項目６９）
集約デジタル署名を検証する方法であって、
デジタル署名が、
複数の署名手段のそれぞれによって与えられた第１の個別値から算出された第１の値を用いて生成された第１の署名要素と、
上記複数の署名手段のそれぞれによって与えられた第２の個別値から算出された第２の値を用いて生成された第２の署名要素とを有する、
該デジタル署名を取得するステップと、
結合公開鍵を生成するために、上記複数の署名手段それぞれの個別公開値を組み合わせるステップと、
署名検証工程における少なくとも１工程で上記結合公開鍵を用いるステップとを含む、方法。
（項目７０）
上記第１の署名要素は、上記複数の署名手段のそれぞれによって生成された個別の暗号鍵から算出された暗号鍵である上記第１の値を用いて、第１のデータ部分を暗号化することによって、算出されたものであり、
上記第２の署名要素は、上記第１の署名要素と第２のデータ部分とから算出された個々の第２要素を組み合わせることによって算出されたものである、項目６９に記載の方法。
（項目７１）
上記第１の署名要素から上記第１のデータ部分を復号する復号鍵を生成するための一時公開鍵の表記を生成する際に、上記結合公開鍵を用いる、項目７０に記載の方法。
（項目７２）
上記一時公開鍵の表記は、
上記第２の署名要素と、上記第１の署名要素および上記第２のデータ部分から算出された中間署名要素の整数表記とを用いて算出されるものである、項目７１に記載の方法。
（項目７３）
上記第１の署名要素は、上記第１の個別値の組み合わせである上記第１の値の関数にしたがって算出されたものであり、
上記第２の署名要素は、上記第２の値と上記第１の署名要素とを用いて算出されたものであり、
上記第２の値は、上記複数の署名手段それぞれからの秘密値を組み合わせることによって算出された結合秘密鍵である、項目６９に記載の方法。
（項目７４）
上記署名検証工程は、ＥＣＤＳＡである、項目７３に記載の方法。
（項目７５）
項目６０から７４までのいずれか１項に記載された方法の各ステップを暗号処理装置に実行させるためのコンピュータ実行可能な命令を記録したコンピュータ読み取り可能な記録媒体。
（項目７６）
項目６０から７４までのいずれか１項に記載された方法に従って、集約デジタル署名を生成する暗号処理装置。

以下に本発明の実施形態について、添付図面を基にして、例を挙げて説明する。

図１は、ＲＦＩＤ認証システムを示す概略ブロック図である。 図２は、図１における、認証機関（ＣＡ）、署名端末、および、検証装置を示す概略ブロック図である。 図３は、一般的なＲＦＩＤタグの概略図である。 図４は、２つの異なるＲＦＩＤ識別（ＩＤ）コードのブロック図である。 図５は、２５６ビットＲＦＩＤタグの概略図である。 図６は、鍵配信の処理の流れを示すフローチャートである。 図７は、署名の処理の流れを示すフローチャートである。 図８は、図７のプログラム処理の流れを示すフローチャートである。 図９は、検証の処理の流れを示すフローチャートである。 図１０は、ＲＦＩＤ認証システムにおける鍵配信用の鍵管理システムと、そのサプライチェーンとを示す概略ブロック図である。 図１１は、図１０の製造段階を示す概略ブロック図である。 図１２は、図１０のリーダの製造業者を示す概略ブロック図である。 図１３は、図１０のＫＭＳを示す概略ブロック図である。 図１４は、図１０の診療所／薬局を示す概略ブロック図である。 図１５は、鍵生成およびタグ署名処理の流れを示すフローチャートである。 図１６は、リーダ登録の処理の流れを示すフローチャートである。 図１７は、鍵配信の処理の流れを示すフローチャートである。 図１８は、資金追跡の処理の流れを示すフローチャートである。 図１９は、半集約署名（semi-aggregate signature）生成方式を示す概略ブロック図である。 図２０は、半集約署名検証方式を示す概略ブロック図である。 図２１は、他の半集約署名生成方式を示す概略ブロック図である。 図２２は、他の半集約署名検証方式を示す概略ブロック図である． 図２３は、完全集約署名（fully aggregate signature）の生成方式を示す概略ブロック図である。 図２４は、完全集約署名の検証方式を示す概略ブロック図である。 図２５は、さらに他の集約署名生成方式を示す概略ブロック図である。 図２６は、さらに他の集約署名検証方式を示す概略ブロック図である。

〔ＲＦＩＤ認証システム、および、サプライチェーン例〕
図１を参照して、ＲＦＩＤ認証システム１０を説明する。図に示されるシステム１０は
、一実施形態において、公開鍵の配信を管理するための証明書を発行する認証機関（ＣＡ
）１２と、対象物１８（医薬品、消費者製品、荷物、携帯通信装置など）に付けられたＲ
ＦＩＤタグ２０を読むためのＲＦＩＤリーダ１４であって、サプライチェーン（supply c
hain）の過程で配置される、任意の数（Ｎ個）のＲＦＩＤリーダ１４と、タグ２０に電子
起源情報（electronicpedigree）を創るときに、ＲＦＩＤタグ２０に署名を書き込むた
めの、任意の数（Ｔ個）の署名端末（signature station）１６とを備えている。各リー
ダ１４は、タグ２０を作動させる無線周波（ＲＦ；radio frequency）領域２６を発生さ
せる。この例の場合、タグ２０は、パッシブタイプであることが望ましい。また、特定の
用途のために費用が正当であるとされるなら、タグ２０はアクティブタイプであってもよ
い。

ＣＡ１２は、証明書を発行することにより鍵配信が容易にできるように、また、必要に
応じてログの報告が容易にできるように、通信経路（communication channel）２４を通
して、リーダ１４および署名端末１６と通信することが好ましい。通信経路２４は、（暗
号化という保護手段により安全または安全でない）ローカルネットワークもしくは広域ネ
ットワークなどの電子的経路であってもよい。あるいは、通信経路２４は、ＣＤ−ＲＯＭ
ディスクなどの媒体の配布、または、技術者を配置することによっても実現できる。した
がって、リーダ１４および署名端末１６はネットワークを介して協働して、または、単独
で動作できるものである。

いくつかの用途において、特定のリーダ１４と署名端末１６とは、ほとんど関係がない
か、または、全く関係がなくてもよく、よって、上記特定のリーダ１４と署名端末１６と
が別々の通信者（party）によって制御されることがある。従って、各通信者は、各リー
ダ１４が署名端末１６によって書き込まれた署名を各々検証できるように、ＣＡ１２と個
別に接続し、通信することが必要である。ＣＡ１２が含まれる構成は、一実施形態に過ぎ
ず、後述のように、別の管理主体または制御主体も使われてもよい点については理解され
たい。

図２に示す概略ブロック図は、ＣＡ１２、署名端末１６、および、リーダ１４間の鍵配
信の一般的な実施形態を示す。ＣＡ１２は、署名端末１６とリーダ１４との両者に証明書
を発行する。ＣＡ１２は、また、図に示されない他のＣＡがリーダの証明書を発行できる
ように、副ＣＡへの証明書も発行できる。これらの証明書は、公開鍵を配信し検証するた
めに使われる。そして、証明書は通常はＲＦＩＤタグ２０に保存されていない。それらの
証明書はタグ２０上に保存されていないため、すべての署名リーダ１６用の証明書の鎖（
chain）全体は、各リーダ１４に分配される。その結果、各リーダ１４は、タグ２０に書
き込まれたいずれの署名もそれぞれ検証することができる。ＣＡ１２は、暗号化作業を行
い、証明書を生成するための暗号モジュール３０を備えている。ＣＡ１２はまた、鍵、お
よび、証明書を保存するための安全な記憶装置３２を備えている。各ＣＡ１２は、ＣＡ証
明書Ｃ_ＣＡを有し、さらに、配信されるべき、署名端末１６の公開鍵Ｗ_１−Ｔ、リーダの
公開鍵Ｚ_１−Ｎ、ならびに、それぞれの証明書であるＣ_{ＳＩＧＮ１−Ｔ}とＣ_{ＶＥＲ１−Ｎ}
とを保存する。一般的に、（図１のような任意の指定に基づいて、）ｊは１からＴまでの
うちのいずれかの数であり、特定の署名端末１６を指す。ｉは１からＮまでのうちのいず
れかの数であり、特定のリーダ１４を指す。

一実施形態においては、ＣＡ１２は、（公開鍵Ｚ_１−Ｎにそれぞれ対応する）リーダ１
４の秘密鍵を生成し、その生成した秘密鍵を証明書Ｃ_{ＶＥＲ１−Ｎ}とともに、大容量暗号
セットにしてまとめてリーダ１４の製造業者に提供する。この実施形態では、鍵を生成す
る作業者が、暗号化されていないアクセスを秘密鍵に対して行わなかったことを、ＣＡ１
２が証明できるので、鍵の整合性がさらに確実になる。図１１に基づいて、秘密鍵の付与
、および、リーダ１４の製造について以下に説明する。

署名端末１６は、ＲＦＩＤリーダに取り付けられていて、暗号モジュール３０ａを用い
て楕円曲線暗号（ＥＣＣ；elliptic curve cryptography）署名を生成し、生成したＥＣ
Ｃ署名をＲＦＩＤタグ２０に書き込むことができる。署名端末１６は、他の署名手段（ot
her signers）１６からの署名を確認するのには用いないことが好ましい。これにより、
通常、署名時、および、検証時には、他のＲＦＩＤリーダからの証明書に当該署名端末１
６がアクセスする必要がなくなる。図２において、署名端末１として示された署名端末１
６は、鍵記憶領域３４に保存された秘密鍵／公開鍵対（ｗ_１，Ｗ_１）と、ＥＣＣ暗号モジ
ュール３０ａとを有する。秘密鍵ｗ_１は、安全なハードウェアに保存され、パスワード、
または、別の仕組みで保護されていることが好ましい。

リーダ１４は、署名端末１６によりタグ２０に書き込まれた署名の検証に使われる。リ
ーダ１４は、通常、署名を生成するのには使われない、または、署名を生成できない。各
リーダ１４は、例えば、リーダ１なら、リーダ１用の鍵対（ｚ_１，Ｚ_１）というように、
それ自身の鍵対を有する。秘密鍵ｚ_１は、署名端末の証明書Ｃ_{ＳＩＧＮ１}を復号化するの
に用いられる。公開鍵Ｚ_１は、秘密鍵ｚ_１に対応しており、対応する証明書Ｃ_ＶＥＲ１を
有する。リーダ１４は、さらに、ＣＡ証明書Ｃ_ＣＡの写しと、さまざまな署名端末１６の
正当性が確認された公開鍵Ｗ_ｊのリストとを保管している。また、リーダ１４は、証明書
の正当性を検証したり、ＥＣＣ署名を検証したりする機能を持つ暗号モジュール３０ａを
備えている。

〔楕円曲線暗号化方式を用いたＲＦＩＤ認証方式〕
図３は一般的なＲＦＩＤタグ２０を示す。タグ２０は、主として、データ保存用に使わ
れる。そして、タグ２０のためのファームウェアは、製造段階でロックされる。そのため
、これらのタグ２０は、一度工場から出荷されると、一組の決まったコマンドセットに対
応する。コマンドは、データブロックの読み取り、書き込み、および、ロックを行うため
に用いられる。図３は、そのようなタグ２０の典型的なメモリ構成を示す。図３に示され
る例において、タグ２０は、３２ビットの各ブロックに区分される。各ブロックは、ファ
クトリーロックビット（Ｆ）（factory lock bit）とユーザロックビット（Ｕ）（user l
ock bit）との２つのロックビットを有する。製造時に、タグ２０は、通し番号を付与さ
れる。本例においては、通し番号には、２ブロック、すなわち、６４ビットが費やされる
。通し番号は、確実に各タグに固有のものとなるように、信頼できる通信者によって、読
み出し専用メモリ（ＲＯＭ）に焼き付けて記録されることが好ましい。製造時、構成デー
タ（configurationdata）が更にタグ２０に加えられる。この例では、構成データに、１
ブロック全て、または、一部（すなわち、３２ビット以下）が費やされる。製薬サプライ
チェーンなどの用途においては、適切な規格や規則に基づいて、製品タイプ識別子などの
製品固有の情報が、さらに追加される。この例では、製品タイプ識別子には３ブロックま
たは９６ビットが費やされる。タグ２０上の残りのメモリは、例えば、デジタル署名を含
む、ユーザデータ用に確保される。図３では、任意のＮブロックをユーザデータとする例
を示す。広く使われている２０４８ビットのタグは、このようにして、署名の保存用に６
４ブロックのデータを提供する。２５６ビットのタグは８ブロックのデータを提供する。

図５は、ＲＦＩＤ認証システムに用いられる２５６ビットのタグ２０の例を示す。この
例において、通し番号は、固有識別子（ＵＩＤ；unique identifier）である。この固有
識別子は、工場でプログラムされてロックされるものであり、タグ２０のそれぞれにユニ
ークであって、通常６４ビットのものである。構成データは、データ保存形式識別子（Ｄ
ＳＦＩＤ；datastorage format identifier）と、アプリケーションファミリー識別子（
ＡＦＩ；applicationfamily identifier）とを含む。ＤＳＦＩＤは、ユーザデータがど
のように暗号化されてタグ２０に保存されたかを特定するために用いられる。アプリケー
ションファミリー識別子は、複数の番号方式のうち、（該当する場合は）ＵＩＤがどの番
号方式に対応するかを特定するために用いられる。この例では、ＤＳＦＩＤ、および、Ａ
ＦＩには、それぞれ８ビットが費やされる。よって、ＤＳＦＩＤとＡＦＩとが同じブロッ
クに書き込まれた場合には、１６ビットの空ビットが残る。あるいは、ＤＳＦＩＤとＡＦ
Ｉがそれぞれ連続する別々のブロックに書き込まれた場合には、４８ビットの空ビットが
残ることになる。図５においては、製品タイプ識別子は９６ビットのＥＰＣグローバル製
品ＩＤ（EPCglobalproduct ID）である。以下に書かれているように、少なくとも、その
製品ＩＤの一部には、タグ２０が付けられた製品１８に関して、細心の注意を要する機密
事項、または、極秘情報が含まれていることがある。よって、適切な保護手段が適所に備
えられておらず、どのリーダ１４も製品ＩＤの上述のような大事な部分を読み取れるので
はないかという、秘密に関する懸念が発生する。２５６ビットのタグでは、ユーザデータ
において、デジタル署名用に８ブロックが確保される。

ＲＳＡ署名は大きすぎて、２５６ビットのタグ２０には書き込めず、代わりに、２０４
８ビットのタグ２０のようにサイズの大きなタグが必要となると理解されたい。ＲＳＡ署
名は５１２ビットのような他のサイズのタグ２０にも大きすぎると理解されたい。さらに
、ＲＳＡ署名が、ある元のタグから読み出されて別のタグにプログラムされる時には、Ｒ
ＳＡ署名を複製することが可能である。しかし、タグ２０は固有のものであり、再プログ
ラミングできないので、複製された署名は、上手く検証されない。図３からもわかるよう
に、ＲＳＡ署名のような署名には、タグ２０のかなりの部分が費やされてしまう（または
、比較的多数のユーザデータブロックがあることが必要である）。そして、タグ２０を極
めて高価なものしなければ、タグ２０にはひとつの署名しか収容できない。

例えば、１０２４ビットのＲＳＡ署名をＲＦＩＤタグ２０への書き込んだり、ＲＦＩＤ
タグ２０から読み出したりすることは、製造工程において深刻なボトルネックとなってい
る。したがって、同じレベルの安全性を維持したまま、ＲＳＡ署名をサイズの小さな署名
で置き換えることが望ましい。１０２４ビットＲＳＡ署名のサイズは、１署名しか収容で
きない比較的大きなサイズの（例えば、２０４８ビットの）ＲＦＩＤタグを必要とする。
そのようなボトルネックを緩和し、１つのＲＦＩＤタグ２０に複数の署名（例えば、製造
工程における各段階を表す）を含めることを可能とし、より小さな（よって、より安価な
）ＲＦＩＤタグ２０を利用可能とするために、安全性は同様であるがサイズが小さな署名
が必要となる。楕円曲線暗号（ＥＣＣ）署名は、特に、以下の分析を検討すると、これら
の特徴を与えるのに適しており、利点があると認められてきた。

ＥＣＣは、限定された領域にある楕円曲線上の点に定義される代数方式において実現さ
れ、ＥＣＣを用いた暗号方式は、有限グループにおける離散対数問題の解決の困難性に基
づくものである。

一例において、そのようなＥＣＣ暗号方式の領域パラメータは、ｙ^２＝ｘ^３＋ｄｘ＋ｃ
の形式の曲線およびシード点（seed point）Ｐである。上記方式において対応するものの
１つには、秘密鍵ａ、０＜ａ＜ｎ（ここで、ｎは点Ｐの次数（the order）である）、お
よび、対応する公開鍵Ｑ_Ａ＝ａＰがある。公開鍵は、認証機関（ＣＡ）に保持されてもよ
い。以下の原理は、２値の

アプリケーションに適用可能である。

ＲＳＡと比較して、ＥＣＣはより小さいサイズで同等の安全性を提供する。「鍵管理へ
の提言 ・ パート１：全改訂版」（“Recommendation for Key Management - Part 1：
General Revised”，NISTSpecial Publication800-57，米国標準技術研究所（National
Institute ofStandards and Technology）， ２００６年５月）から抜粋された下記の
表においては、同等の安全性レベルにて、ＥＣＣビットサイとＲＳＡビットサイとの比較
がなされる。

１０２４ビットのＲＳＡ署名と同等の安全性レベルを得るために、１６０ビット以上の
楕円曲線が用いられるべきである。ここで挙げられる例では、ＥＣＰＶＳ（elliptic cur
vePintsov-Vanstone signature）方式の使用およびＥＣＤＳＡ（elliptic curve digita
l signaturealgorithm）方式の使用と、ＲＳＡのような公開鍵方式の使用とを比較する
。他のＥＣＣ方式も適用できるものと解される。

ＥＣＰＶＳは、メッセージ復元を伴うデジタル署名方式である。これは、署名されたメ
ッセージの一部が、署名検証処理で復元されることを意味する。ＥＣＰＶＳは、ＩＥＥＥ
１３６３ａ−２００４、および、ＩＳＯ／ＩＥＥＥ９７９６−３に定められている。また
、ＡＮＳＩ基準案として定められている。ＥＣＰＶＳでは、署名されたメッセージＭは、
２つの異なって区別される部分からなる、あるいは、データＨとデータＶとのセット（例
えば、Ｍ＝Ｈ｜｜Ｖ）であると考えられる。ここで、Ｈは署名に隠される、そして、検証
処理中に復元されるメッセージ、または、データセットであり、Ｖは同様に署名されるが
、明らかな状態で（そうでなければ、容易に、または、公に利用可能な状態で）送られ、
検証処理に使われるメッセージ、または、データセットである。メッセージＨは、特定の
検証鍵を持つエンティティによってのみ復元可能である。そして、メッセージＶは、例え
ば、ＲＦＩＤリーダ１４などのいずれのエンティティによっても、つまり、署名を検証す
ることなしに、読み出し可能である。

ＥＣＰＶＳ署名生成アルゴリズムは、通常、署名の正当性を確認するための署名検証中
に検査することができるメッセージＨに特有の特徴を特定することによって始まる。例え
ば、メッセージＨが、実存する偽造攻撃を防ぐために十分な、所定の制限を越えるある量
の冗長性を有するかどうかを判断してもよい。メッセージＭを形成する元のデータが十分
な冗長性を含むと判断される場合、メッセージＨは単純にそのデータの部分集約である可
能性がある。所定の冗長性が見つからない場合、メッセージＨは、余分のゼロのような、
人為的に加えられた冗長性を含むように変更されている可能性がある。ある量の冗長性を
持つことは、単に一つの特徴であり、それ以外の既知の予想される値と比較可能ないずれ
の文字列やデータセットなどが用いられてもよいと解される。

例えば、８０ビットの冗長性は、通常、１０２４ビットのＲＳＡと同等レベルの安全性
を出すために必要なものである。そして、８０ビットの冗長性は、１０２４ビットのＲＳ
Ａと同等またはそれ以上の安全性が望まれる場合、最低閾値として選択されるべきもので
あることが好ましい。しかし、下記にあるように、用いられる冗長性の量は、所望のタグ
のサイズと、（署名の偽造が非経済的であるとする場合、または、別のやり方で受け入れ
られる場合における）最低限の安全レベルとに基づいて用途に合うように仕立てられる。
以下、ＥＣＰＶ署名生成の要約を述べる。

まず、一時的な鍵対（ｋ，Ｑ）が生成される。ここで、Ｑ＝ｋＧは、楕円曲線上の点で
あり、ｋはランダムな整数１≦ｋ＜ｎであり、ｎは楕円曲線上の基点Ｇによって生成され
るグループの次数（order）である。次に、鍵ｋ_１＝ＫＤＦ（Ｑ）が構成される。ここで
、ＫＤＦは、鍵導出関数である。一般的に、鍵導出関数は、秘密の値（secret value）、
および／または、他の既知の情報から、秘密鍵を導出するために用いられる。ＥＣＰＶＳ
において、ＫＤＦは、点Ｑ、および、可能であれば他の情報を入力値として受け取り、暗
号鍵ｋ_１を生成する。それから、署名エンティティは、第１の署名要素（first signatur
e component）ｃを、

のように計算する（すなわち、鍵ｋ_１を用いたメッセージＨの暗号化）。ここで、ＥＮＣ
は、平文（例えば、Ｈ）を入力として受け取って、暗号文ｃを作るために、その平文を鍵
ｋ_１用いて暗号化する適切な暗号化方式を示す。

次に、中間要素ｈがｈ＝Ｈａｓｈ（ｃ｜｜Ｖ）として算出される。ここでＨａｓｈは、
適切なハッシュ関数（例、ＳＨＡ１）である。好ましくは、例えば、署名元の証明書や識
別情報などの、署名を検証する当事者が利用できる、または、利用できるようになる、追
加の情報（言い換えれば、検証装置が検証用に「検証側で」必要とする情報）が、ｈに組
み込まれていてもよい。中間要素ｈは、それから整数ｅに変換される。そして、第２の署
名要素ｓが、シュノール（Schnorr）アルゴリズムのような適切な署名アルゴリズムを用
いて計算される。ここで、ｓ＝ｅ・ｗ＋ｋ ｍｏｄ ｎであり、ｗは、署名手段（つまり、
上記の例における署名端末）の長期秘密鍵である。そして、結果として得られる署名は、
（ｃ，ｓ，Ｖ）または（ｓ，ｃ｜｜Ｖ）である。

以下に、署名手段の真の公開鍵（signing entity’s genuine public key）Ｗが与えら
れた場合の、署名（ｓ，ｃ｜｜Ｖ）についてのＥＣＰＶ署名検証を示す。まず、中間要素
ｈが、要素ｃ｜｜Ｖと、署名段階で使われたものと同じハッシュ関数と、署名元の識別情
報などの追加情報とを用いて算出される。ここで、ｈ＝Ｈａｓｈ（ｃ｜｜Ｖ）である。次
に、ｈは、整数ｅに変換される。それから、一時的な公開鍵の表記Ｑ’が、整数ｅ、署名
元の公開鍵Ｗ、基点Ｇ、および、署名要素ｓを用いて算出される（例えば、Ｑ’＝ｓＧ−
ｅＷにしたがって算出される）。

次に、復号鍵ｋ_１’は、署名段階で使われたものと同じ鍵導出関数ＫＤＦを用いて、同
じ追加情報を含めて算出される。すなわち、ｋ_１’＝ＫＤＦ（Ｑ’）にしたがって算出さ
れる。上記で導出された鍵、および、復号化補関数（complementary decryption functio
n）ＤＥＣを用いて、要素ｃを復号化することによって、Ｈ’で表されるＨの隠された部
位は復元される。すなわち、

のように復元される。それから、検証装置が、例えば、Ｈ’に含まれる冗長性など（特定
の形式など）の特定の特徴をチェックする。Ｈ’にある所定量の冗長性など必要な特徴が
含まれる場合、Ｈ’は有効なメッセージであり、署名の正当性が確認される。Ｈ’が必要
な冗長性を含まない場合、効力のない無効な署名は返送される。

メッセージＭは細分されているので、例えば、Ｈなどの１部分のみが、冗長性等の必要
条件の特徴を含み、隠されていればよい。別の部分Ｖは、元のメッセージと同じ構造をも
つ平文なので、帯域の効率を向上させることができる。そのため、ＲＦＩＤタグについて
、可視部Ｖは、ＲＦＩＤリーダ１４が利用できるどんなデータ部分を含んでいてもよい。
ｃに隠された部分Ｈは、署名元の公開鍵Ｗを持つ者しか利用できないが、Ｖに含まれるデ
ータは全ての者が利用できる。データの一部が、機密情報を見られないように隠されてい
るという、ここで説明された原理は、特に、下記で示される、製薬サプライチェーンに適
している。しかし、この原理は、どのような製品のタイプのどのようなＲＦＩＤ認証シス
テムにも、また、認証と秘密または機密保持とが望まれるどのような環境におけるどのよ
うなＲＦＩＤ認証システムにも、同様に適用できるものと理解できる。例えば、下記の原
理は、空港で荷物を追跡したり、製品を追跡したり、あるいは、ＲＦＩＤ技術を利用した
携帯機器の利用者を認証したりすることなどにも適用できる。

ここに記述されるＲＦＩＤシステム１０の認証においてＥＣＰＶＳを使用すると、タグ
２０の識別情報の一部を、権限のないリーダに対して秘密にできる。その一方で、従来の
リーダに対して、残りのデータ（例えば、通常の読み取り動作用のデータ）の読み取りを
可能にする。これは、データの特定の部分を署名によって隠すことができるとともに、他
の機密でない情報は単にそのままタグ２０に残したり、平文Ｖの一部として含まれた状態
で残したりすることができるためである。また、ＥＣＰＶＳ署名は、１０２４ビットのＲ
ＳＡ署名よりサイズが小さいため、同等の安全性をもったまま、より小さいタグを使うこ
とができる。例えば、以下で非常に詳細に説明されるように、５１２ビットのタグ、また
は、２５６ビットのタグが、用途、必要な安全性レベル、および、タグの利用可能性に応
じて、使用できる。

図４は、製品識別（ＩＤ）コード４０（例、ＥＰＣグローバルコード）の概要を示す図
である。このＩＤコード４０は、以下の説明において、９６ビットであるとする。変形例
（ａ）は、ヘッダ５０ａと通し番号５２ａとを含む。変形例（ｂ）は、ヘッダ５０ｂ、通
し番号５２ｂ、および、製品ＩＤ５４を含む。製品ＩＤ５４は通し番号５２ｂの一部であ
ってもよいし、別個のコードであってもよい。製品ＩＤ５４は、タグ２０が付けられた製
品のタイプを明示するものである。

製薬産業のような産業においては、変形例（ｂ）のＩＤコード４０ｂを使うことは、Ｉ
Ｄコード４０ｂは製品が何であるかを明らかにするので、秘密に関する問題を引き起こす
と考えられてきた。したがって、正当でないリーダが、必要条件範囲内にある場合に、消
費者が何を購入しているのかを判別する可能性があった。このような秘密に関する懸念は
、米国食品医薬品局（ＦＤＡ）のレポートである“ＦＤＡ偽造薬品対策委員会レポート：
２００６更新（FDACounterfeiting Drug Task Force Report:2006 Update）”で扱われ
ている。このレポートの一部で、ＲＦＩＤタグでは、薬品を識別する情報を含むＮＤＣ番
号を明らかにしないことが推奨されている。

そのため、変形例（ｂ）を使った場合、正当でないリーダが製品タイプを判別できない
ように、少なくとも製品ＩＤ５４を暗号化するか隠すことが望ましい。署名すべきメッセ
ージとしてＩＤコード４０を指定することによって、そして、製品ＩＤ５４を、隠されて
検証時に復元される部分Ｈとして指定することによって、署名の中に製品ＩＤ５４を隠す
ことが可能な、サイズおよび効率の上で適切なＥＣＣ署名方式を、ＥＣＰＶＳが提供する
ことが認識されている。

また、ＥＣＰＶＳと、変形例（ａ）または変形例（ｂ）とを使うと、ＩＤコード４０の
全体をＨとして選択することができる。そして、復元できない部分または可視部Ｖは、Ｕ
ＩＤとすることができる。単純な例において、ＥＣＰＶＳは、以下の表にあるように、デ
ジタル署名を２５６ビットの記憶領域（図５参照）を持つＲＦＩＤタグ２０に収めること
ができる。

実用的な実施において、いくつかの問題を検討しなければならない。第一に、ＩＤコー
ド４０全体が（署名検証中に復元されるように）隠された場合、ＥＣＰＶＳに対応しない
、または、正しい公開鍵Ｚ_ｉを持たないリーダ１４は、ＩＤコード４０を全く読み取るこ
とができなくなる。ＩＤコード４０自体は、（例えば、製品ＩＤ５４が復元可能な場合）
復元可能な部分、または、復元不可能な部分に分けられる。しかし、復元可能な部分の冗
長性が不十分になる可能性がある。ＩＤコード４０が細分化される場合に、追加の冗長性
が求められるおよび／または十分な安全性を提供するために冗長性を追加する別の方法（
例えば、埋め込み（padding））の検討が必要とされるならば、ＲＦＩＤタグ２０は、大
きくせざるを得なくなる可能性がある。

第２に、ＩＥＥＥ基準１３６３ａ−２００４は、復元可能なメッセージＨには、少なく
とも１バイトを埋め込むことを規定している。この基準に従うことが望ましいならば、余
分なバイトを記憶するための領域が必要となる。第３に、２５６ビットのタグ２０が使わ
れる場合、ＡＦＩＤにおいて未使用のビットのうち、いくつかを使わない限り、署名時刻
などのデータを保存する場所がない場合がある。最後に、署名が有効かどうかを検証装置
１４が決定できるのに十分な冗長性が、ＩＤコード４０の中にない場合がある。何らかの
帯域外情報（outof band information）（例えば、紙ラベルでの目に見える検証）が必
要になる可能性がある。以下で、冗長性の問題を扱う。

上述したとおり、２つのタイプのＩＤコード４０ａと４０ｂがある。変形例（ａ）の領
域は、直接的には製品に関連付けられていない。変形例（ｂ）のコード４０ｂにおいては
、製品ＩＤ５４が、直接的に製品を特定する。したがって、少なくとも製品ＩＤ５４を暗
号化して（すなわち、製品ＩＤ５４を隠しメッセージＨの少なくとも一部分として）、隠
すことが望ましい。

用途によっては、ＩＤコード４０は十分な冗長性を含まない場合があり、パターンまた
は制限が、署名偽造の脆弱性を回避するための領域に課される場合があると理解できる。

１６０ビットの曲線と、ハッシュ関数としてＳＨＡ−１とを用いた場合、通常の目安と
して、８０ビットの冗長性を用いる。しかし、偽造署名は、ある特定の１つのＲＦＩＤタ
グ２０に対して限定されるので、より小さいビット数で事足りる場合もある。さらに、１
つの署名を偽造するための計算量および／または計算時間は、偽造者が署名を偽造しよう
と企むことを阻止するのに十分なほど長い。安全性レベルは、そのような偽造者に対する
十分な抑止力を与えるように合わせられていればよい。

１０２４ビットのＲＳＡ署名と同等な安全性レベルを提供するために、１６０ビット曲
線のＥＣＰＶＳ署名が、図５に示される２５６ビットの構造に適合している。（もしあれ
ば）製品ＩＤ５４、および、冗長性を含むＩＤコード４０の一部のような「他の」部分が
、復元可能なメッセージＨを形成する。そして、ＩＤコード４０の残りの部分およびＵＩ
Ｄは、復元不能な部分Ｖを形成する。復元不能な部分Ｖから利用可能な情報は、署名端末
１６を識別するのに十分でなければならない。例えば、暗号鍵ｋを使って、署名要素ｃは
、ｃ＝ＥＮＣｋ（製品ＩＤ＋その他）のように計算される。また、可視部Ｖとみなされる
通し番号とＩＤコード４０のヘッダとを使って、中間要素ｈがｈ＝ＨＡＳＨ（ｃ｜｜通し
番号＋ヘッダのように計算される。この例において、どんなリーダ１４も、通し番号とヘ
ッダ情報とを読み取ることができるが、製品ＩＤ５４を復号するためには、適切な検証鍵
（例、Ｗ）へのアクセスが必要となる。

８０ビットの冗長性がないかぎり、ＥＣＰＶＳは、１０２４ビットのＲＳＡと同等レベ
ルの偽造署名に対する耐性を提供することができない。しかし、各偽造署名は、１つの特
定のＲＦＩＤタグ２０にしか適用できないので、他の署名は改ざんされないであろうから
、より低いレベルの耐性でも受け入れられる場合がある。

埋め込み（padding）なしにＥＣＰＶＳを実施するために、かつ、ＲＦＩＤタグ２０に
おいて追加領域が冗長性を増やすのに利用できない場合でも署名が有効かどうかを判断す
るには、ＩＤコード４０に内在する冗長性に頼ればよい。これは、特定のパターンや構造
をＩＤコード４０に課すことであったり、あるいは、製造データベースへの参照などのよ
うに、何らかの帯域外情報を用いることであったりしてもよい。ＩＤコード４０の一部が
復元可能な部分Ｈに含まれているので、ＥＣＰＶＳに対応しないリーダ１４は、ＩＤコー
ド４０全体を読み取ることができない。

埋め込み（padding）をしてＥＣＰＶＳを実施するために、ＡＦＩ、ＤＳＦＩＤ、およ
び、ユーザロック（Ｕ）ビットを復元可能な部分Ｈの冗長性を増やすのに用いてもよい。
例えば、図５から理解されるように、ＡＦＩ（それ自身のブロックに書き込みされた場合
）には未使用のビットが２４ビットある。これは、ＤＳＦＩＤ領域、および、ユーザロッ
クに、未使用のビットが８ビットある（ユーザデータブロックをロックしないことが受け
入れられる場合）のと同様である。これらの未使用のビットは、埋め込みを実現するため
に利用可能となる。

埋め込み（padding）の理想的なレベルは、８０ビットである。しかし、特定の用途の
目的に対してより小さい埋め込みでも署名の偽造を無力化（uneconomical）にするのに十
分に安全であれば、それより少ないビット数の埋め込みを用いてもよい。

余分な埋め込みを使えば、ＩＤコード４０に内在する冗長性に頼る必要はない。よって
、製品ＩＤ５４を除くコード４０全体は、復元不可能なメッセージＶとして保存できる。
全てのリーダ１４はＩＤコード４０を読み取ることができるが、正しい公開鍵を持つリー
ダ１４しか製品ＩＤ５４を復元させることはできない。

よって、ＲＳＡで署名されるのに適したＲＦＩＤタグより小さなＲＦＩＤタグ２０に、
ＥＣＰＶＳを使って署名できると分かる。タグ２０にある情報のデータ構造を検討するこ
とで、冗長性の様々なレベルが、そのような冗長性を未使用のブロックに埋め込むことに
よって実現できる。また、ＩＤコード４０が権限のないリーダ１４に読み取られる必要が
ない場合、所望の量の冗長性を実現するために、ＩＤコード４０内の冗長性に頼ることが
できる、または、その冗長性を課すことができる。よって、ＲＦＩＤタグ２０上のＥＣＣ
署名を使うことにより、より小さく、効率的となる一方で、ＲＳＡ署名と同等の保護を提
供することができると理解される。これにより、より小さなタグを使用することができ（
あるいは、利用可能なデータブロックをより効率的に使用することができ）、および／ま
たは、１つのタグに複数の署名を納めることができる。これは、ＲＳＡ署名を用いたので
は、その全体のサイズのせいで、実現不可能である。

ここで説明されたＥＣＰＶの使用に関する原理は、メッセージ復元を伴うほかの署名方
式にも同様に適用できると理解される。他の署名形式の一例としては、復元を伴う楕円曲
線デジタル署名（ＥＣＤＳＲ；the Elliptic Curve Digital Signature with Recovery）
があり、ＥＣＤＳＲは、「機密メッセージの復元を伴う署名（“Signatures with Confid
ential MessageRecovery”）」と題される米国特許仮出願番号＿＿＿＿＿＿（出願日：
２００７年９月４日）に記載されている。その内容は本明細書が参照することによって組
み込まれる。ＥＣＤＳＲを用いた場合、安全性とタグのサイズとに関して、上述の記載と
同様に考慮される。

他の実施形態において、ＲＦＩＤタグ２０の安全性を確保するために、特に、秘密性が
重要な問題ではない変形例（ｂ）のＩＤコード４０ｂに、ＥＣＤＳＡ署名を用いることが
できる。

ＥＣＤＳＡは、いくつかの基準案と同様に、ANSI Ｘ9.62、FIPS186-2、IEEE1363-2000
、および、ISO/IEC15946-2基準にでてくる、広く標準化された楕円曲線に基づく署名方式
である。

ＥＣＤＳＡ署名生成は、秘密鍵ｄやメッセージｍ等の数個の領域パラメータ（domain p
arameter）に基づいて行われ、署名（ｒ，ｓ）（ｒとｓは整数）を出力する。そのアルゴ
リズムの概要は以下のとおりである。
１．ｋ∈_Ｒ[１，ｎ−１]を選択する。ｎは楕円曲線に基づく点より生成されるグループの
次数（order）であり、領域パラメータの１つである。
２．ｋＰ＝（ｘ_１，ｙ_１）を算出し、ｘ_１を、

に変換する。ここで、Ｐは楕円曲線Ｅ上の点であり、領域パラメータの１つである。
３．

を算出する。ここで、ｒ＝０であれば、ステップ１に戻る。
４．ｅ＝Ｈ（ｍ）を算出する。ここで、Ｈは、暗号ハッシュ関数を示し、その出力は、ｎ
のビット長以下である（この条件が満たされない場合、出力Ｈは切り詰められる）。
５．ｓ＝ｋ^−１（ｅ＋ｄｒ） ｍｏｄｎを算出する。ここで、ｓ＝０であれば、ステップ
１に戻る。
６．対（ｒ，ｓ）をＥＣＤＳＡ署名として出力する。

ＥＣＤＳＡ署名検証は、公開鍵Ｑ、メッセージｍ、および、上記で導出された署名（ｒ
，ｓ）など、いくつかの領域パラメータに基づいて行われる。ＥＣＤＳＡ署名検証では、
署名の“拒絶（rejection）”、または、“承認（acceptance）”が出力される。ＥＣＤ
ＳＡ署名検証は、以下のように進められる。
１．ｒおよびｓが、区間［１，ｎ−１］内にある整数であることを検証する。もし、検証
に失敗したら、“拒絶”を返す。
２．ｅ＝Ｈ（ｍ）を算出する。
３．ｗ＝ｓ^−１ ｍｏｄ ｎを算出する。
４．ｕ_１＝ｅｗ ｍｏｄ ｎ、および、ｕ_２＝ｒｗｍｏｄ ｎを算出する。
５．Ｒ＝ｕ_１Ｐ＋ｕ_２Ｑを算出する。
６．Ｒ＝∞であれば、署名は拒絶される。
７．Ｒのｘ座標ｘ_１を

８．ｖ＝ｒであれば、署名は承認される。ｖ＝ｒでなければ、署名は拒絶される。

上述したとおり、ＥＣＤＳＡ署名は、ｒとｓという２つの整数で構成されている。ｒお
よびｓのそれぞれは、楕円曲線に基づく領域と同じサイズである。例えば、１６０ビット
の曲線を使った場合、署名のサイズは、１６０×２＝３２０ビット、または、４０バイト
となる。

メッセージＭがＥＣＤＳＡで署名される場合、検証装置が正しい公開鍵Ｑを既に持って
いるものとして、Ｍ、ｒ、および、ｓが検証装置に送付される。

ＲＳＡと比較すると、ＲＦＩＤ認証システム１０においてＥＣＤＳＡを使用すると、デ
ジタル署名の読み取り／書き込み時間が短縮される。しかし、ＥＣＰＶＳにあるような機
密性は実現できない。ＥＣＤＳＡを実施する最も単純な方法は、１０２４ビットのＲＳＡ
署名を、同等の安全性を持つＥＣＤＳＡ署名に置き換えることである。曲線サイズは、通
常、最小でも１６０ビット必要がある。よって、ＥＣＤＳＡ署名は少なくとも３２０ビッ
トを占める。ＮＩＳＴに推奨される最小の曲線サイズは、１６３ビットであり、対応する
４２バイトのサイズのＥＣＤＳＡ署名が伴う。以下の表は、ＩＤコード４０が９６ビット
を占めるものとして、必要なＲＦＩＤメモリを示す。

ＥＣＤＳＡ方式を使って署名されたメッセージは、タグ２０のＵＩＤとＩＤコード４０
とを連結したものであってもよい。

変形例（ａ）のコード４０ａには、製品ＩＤ５４は含まれない。署名要素ｒは、埋め込
みのみを用いて、算出される。復元されたメッセージが、予測された埋め込み（the expe
cted padding）と一致する場合、署名は有効である。

変形例（ｂ）では、製品ＩＤ５４は、どの製品にも対応しない無効な値で置き換えられ
てもよい。そして、実際の製品ＩＤ５４、および、埋め込みは、ｒの算出で用いられる。
復元されたメッセージが予測された埋め込みと一致する場合、署名は有効である。そして
、リーダ１４は、正しいＩＤコード４０ｂを形成するために、無効な製品ＩＤ５４を復元
された値に置き換えることができる。

選択されるＥＣＣ署名方式は、通常は、ＲＦＩＤタグ２０で利用可能な記憶領域の量に
依存する。使用されるタグのサイズは、許容できる安全性、および、利用可能な記憶領域
のサイズを基に選択され得るということは理解されたい。許容される安全性のレベルは、
通常、偽造者にとって署名を偽造することが経済的に見合っているか否かに基づいて、決
定される。ＥＣＰＶＳ署名における冗長性を減らしても、偽造が不可能な場合、より小さ
なタグを用いることができる。ここでは、２０４８ビットと２５６ビットのタグを用いる
場合の例を、説明のためだけに示す。よって、例えば、５１２ビットのタグなどの他のタ
グサイズを、代わりに用いてもよい。

２０４８ビットのＲＦＩＤタグ２０が使われる場合、ＥＣＤＳＡ、または、ＥＣＰＶＳ
のどちらかが使われる。ＥＣＤＳＡは、ＲＳＡ署名に置き換えて利用することができる。
そして、そのデジタル署名は、１０２４ビットではなく３２０ビットを占有するだけあり
ながら、同等の安全性レベルを実現する。ＩＤコード４０を含めて、必要とされる全記憶
領域は４１６ビット、すなわち、１３メモリブロックである。よって、ＥＣＤＳＡを使う
ことで、同等の安全性を提供し、読み出し／書き込み時間を短縮するとともに、複数の署
名が１つの２０４８ビットのタグ２０に書き込むこと可能になると分かる。これによって
、製品１８が、サプライチェーン２２を進む時に、電子起源情報（electronic pedigree
）を作成可能となる。しかし、ＥＣＰＶＳと異なり、ＥＣＤＳＡでは製品ＩＤ５４を隠す
ことができない。

署名サイズをさらに減らし、適切な公開鍵Ｚ_ｉを持たないリーダ１４に対して、製品Ｉ
Ｄ５４を隠すために、ＥＣＰＶＳを用いることができる。２０４８ビットのタグ２０に余
分な保存スペースがあれば、冗長性を許容されるレベルまで増やすために埋め込み（padd
ing）を使うことができる。ＩＤコード４０に内在する冗長性を考慮しなければ、１０２
４ビットのＲＳＡ署名と同等の安全性を実現するために、８０ビットの埋め込みを追加す
ることが可能である。必要な記憶領域の合計は、ＩＤコード４０に９６ビット、製品ＩＤ
５４に２０ビット、そして、ｒに８０ビットの埋め込みとｓに１６０ビットの埋め込みで
ある。よって、合計３５６ビットまたは１２メモリブロックが、埋め込みがなされたＥＣ
ＰＶＳ署名に使われる。安全性についてより低いレベルが許容できる場合、メモリの必要
条件はさらに緩和できる。以下の表には、２５６ビットと２０４８ビットのＲＦＩＤタグ
に使われる署名方式の概要が示される。

よって、ＥＣＰＶＳを用いた２０４８ビットのＲＦＩＤタグ２０により、例えばサプラ
イチェーン２２の異なる段階などで、複数の署名をタグに書き込むことが可能になること
がわかる。また、システム１０が、権限のないリーダに対して製品ＩＤを隠すことが可能
となり、秘密性を追加することができるとわかる。上記記載は、専ら説明用と解され、上
記に述べられたような原理および検討に基づき、他のタグサイズが適している場合もある
ということを理解されたい。

結果、許容される安全性のレベルおよびＩＤコード４０により与えられる内在的な冗長
性などの特定のパラメータを用いて、埋め込みを伴うＥＣＰＶＳ、および、埋め込みを伴
わないＥＣＰＶＳを使って、例えば、２５６ビットのＲＦＩＤタグ２０、または、５１２
ビットのＲＦＩＤタグ（図示されない）のようなより小さいタグ２０を用いることができ
る。

ＥＣＰＶＳが製品ＩＤ５４を隠すために使われる場合、リーダ１４に保存される公開鍵
Ｚ_ｉは、物理的に保護されるべきである。そして、鍵の配布は、例えば、ＣＡ１２によっ
て慎重に制御されるべきである。各リーダ１４がそれ自身の公開／秘密鍵対を含む場合、
証明書が、配布前に、特定の各リーダ１４用に暗号化される。ＣＡ１２は、署名端末１６
とリーダ１４の両方に証明書を発行する。リーダ１４および署名端末１６用の鍵対は、製
造時に生成される。上述のように、各リーダ１４は、署名端末の有効な公開鍵Ｗ_ｊのリス
トを有する。これにより、署名の正当性が検証できる。図６は、署名元の証明書Ｃ_{ＳＩＧ
Ｎｊ}を用いた鍵配布処理の手順の例を示す。

ＣＡ１２は、ステップ１００で、適切な公開鍵Ｗ_ｊを取得して、ステップ１０２で、対
応する証明書Ｃ_{ＳＩＧＮｊ}を生成する。そしてステップ１０４で、証明書の配布先のリー
ダ１４用に、適切な公開鍵Ｚｉを用いて証明書が暗号化されて、これにより、暗号化版の
Ｃ_{ＳＩＧＮｊ’}が得られる。その後、ステップ１０６で、暗号化版のＣ_{ＳＩＧＮｊ’}は、
適切なリーダ１４に配布される。ステップ１０８で、リーダ１４がＣ_{ＳＩＧＮｊ’}を受信
する。ステップ１１０で、暗号化版の証明書Ｃ_{ＳＩＧＮｊ’}は、秘密鍵ｚ_ｉを用いて、リ
ーダ１４によって復号化され、元の証明書Ｃ_{ＳＩＧＮｊ}が取得される。ステップ１１２で
、ＣＡ証明書が取得された場合、ＣＡ証明書ＣＣＡを用いて、ステップ１１４で、上記証
明書が評価される。上記証明書が有効な場合、鍵Ｗ_ｊが、証明書から取得され、安全な鍵
記憶領域３６に保存される。

図７は、ＥＣＤＳＡ、または、ＥＣＰＶＳに適用できる署名処理を示す。示された例で
は、ステップ２００で、署名端末１６が、まず、署名されたタグ２０が署名端末１６にと
って既知の製造業者から来たものかどうかを判断する。製造業者が既知のものであれば、
ステップ２０２で、製造業者ＩＤが選択される。製造業者ＩＤが検出されなかった場合、
ステップ２０４で、署名端末は、製造業者を追加するという選択肢を選ぶ。それにより、
ステップ２０６で、名前が入力される。通常、署名端末は、前もって設定された数の特定
の製造業者だけのために署名をするように、前もってプログラムされている。よって、ス
テップ２００から２０６は、必要がない場合や、オペレータの介入を必要とせずに自動的
に実施される場合がある。ステップ２０８で、署名および曲線のタイプに対応する鍵対が
製造業者用に生成され、該製造業者によって、取り込まれる、あるいは、別のやり方で取
得される。ステップ２１０で、秘密鍵は、安全なハードウェアに保存され、ステップ２１
２で、公開鍵は、ＣＡ１２に連絡される。

そしてステップ２１４で、署名端末１６は、タグ２０から、通し番号を選択するまたは
読み取る（デフォルトのカウンタの値を使ってもよい）。変形例（ｂ）が適用される場合
、ステップ２１６で、製造コードが選択される。上述したとおり、通し番号は、署名する
／プログラムする設備に到達する前に、ＲＯＭに前もって焼き付けられていることが好ま
しい。これにより、署名されていないタグ２０の製造業者は、確実に、安全性を危うくす
るまたはシステムを攻撃するために、単に標準の部品を使って偽造者の目的に合うＵＩＤ
をプログラムするということではできずに、代わりに、ハードウェアを偽造しなければな
らなくなる。

上述したとおり、署名端末１６は、通常、適切な署名タイプを自動的に生成するように
前もってプログラムされているが、オペレータが、タグに書き込む署名のタイプ（例、Ｅ
ＣＤＳＡ、または、ＥＣＰＶＳ）をステップ２１８で選ぶことができるようにし、ステッ
プ２１９で署名を書き込むようプログラムされていてもよい。そして、ステップ２２０で
、タグ２０はプログラムされてもよい。ステップ２２２で、記録が作成され、その記録を
追跡と監視の目的でログレポートとして保存することが好ましい。署名端末が配置される
前に上述の決定が調整されるように、各署名端末１６が前もってプログラムされているこ
とが好ましいと理解される。しかし、望まれるのであれば、上述の決定の構成は、例えば
、グラフィカルユーザインターフェイス（ＧＵＩ）（図示されていない）におけるドロッ
プダウン・リストなどによって、プログラムにて実現されてもよい。また、そのようなＧ
ＵＩは、プログラミングや署名端末１６の修復のために、技術者によって使われてもよい
。

図８は、ステップ２２０のさらに詳細を示す。ステップ２３０で、ＵＩＤが、タグ２０
から読み取られる。そしてステップ２３２で、ＩＤコード４０が、製品タイプなどのユー
ザの選択に基づいて生成される。そしてステップ２３４で、ＵＩＤ、ＩＤコード、あらゆ
るメタデータ、および、あらゆる隠しデータ（例えば、製品ＩＤ５４およびＥＣＰＶＳを
使ったもの）が署名され、製造業者に固有の公開鍵を用いた署名が生成される。その後、
ステップ２３６で、ＩＤコード４０および上記署名がタグ２０に書き込まれる。ステップ
２３８で、署名端末１６の少なくとも内部記録において、タイムスタンプが記録されるこ
とが望ましい。希望に応じて、ログ記録やログレポートが署名端末１６で保存され、後に
、監視や追跡目的のために、登録されたり報告されたりしてもよい。

図９は、検証手順を示す。ステップ３００で、ある時点において、リーダ１４は、ＣＡ
から製造業者に固有の公開鍵Ｗ_ｊを取得する。ステップ３０２で、タグ２０は（パッシブ
タイプタグの場合）、ＲＦゾーン２６に入ると起動される。そしてステップ３０４で、Ｕ
ＩＤ、データおよび署名をリーダ１４が読み取る。それから、ステップ３０６で、リーダ
１４が、公開鍵Ｗ_ｊを使って、採用された署名方式のタイプにしたがって、署名を検証す
る。そしてステップ３０８で、適用可能な場合、タイムスタンプが記録される。ステップ
３１０では、サプライチェーンや製品の整合性に責任ある適切な通信者が、監視目的で使
うことができるログレポートが、生成されることが好ましい。

したがって、ＥＣＣ、特に、適切であればＥＣＰＶＳやＥＣＤＳＡを用いることによっ
て、ＲＦＩＤ認証システム１０において、読み取り／書き込み時間や署名サイズを削減す
ることができることが分かる。ＥＣＰＶＳを使用すると、製品情報の一部分を隠すことが
できるというメリットがさらに加わる。それは、ＲＦＩＤ技術を採用するためのさらなる
動機を与える。また、ＥＣＰＶＳは、ＲＳＡ署名と同等の安全性で、署名サイズを最小と
することができる。より小さなサイズの署名によって、複数の署名端末１６をサプライチ
ェーンで利用することができる。これにより、複数の署名が、各タグに残る利用可能なス
ペースに、順次書き込まれる。この複数の署名は、順次検証が必要とされる。したがって
、製品がサプライチェーンを通って移動する際、製品の所在を追跡することが容易になる
。

〔ＲＦＩＤ認証システムのための鍵管理システム〕
次に、図２の概要で示した鍵配布のための一実施形態として、図１０を参照して、鍵管
理システム（ＫＭＳ）４００を説明する。図１０に示される例では、ＫＭＳ４００は、薬
剤の製造段階、サプライチェーン２２、および、その後の消費者への流通において、鍵配
布の管理を担う。

上述のとおり、薬剤または製品ＩＤコード５４のような秘密情報または機密事項を含む
ＲＦＩＤタグ２０は、ＥＣＰＶ署名を使って隠すことができる。しかし、隠された部分は
、署名端末１６公開鍵Ｗ_１−Ｔおよびリーダ１４の公開鍵Ｚ_１−Ｎそれぞれを使って復元
できるので、全体のシステムが分散したり、拡張したり得るように意図されている場合は
、一般的には、安全な方法でＥＣＰＶ公開鍵を保護し、その公開鍵の配布を監視し、管理
することが望ましい。ＫＭＳ４００は、権限があるリーダ１４のみが、製品ＩＤコード５
４を復元できるように、ＥＣＰＶ公開鍵の配布を管理する目的で使うことができる。よっ
て、以下の例における鍵Ｗ_１−ＴおよびＺ_１−Ｎは、これらの鍵の使用について管理がな
されることによって従来の「公開型」ではないことを前提に、「検証鍵」と称される。

図１０に示されるとおり、製造業者４０２で製造された（ＲＦＩＤプログラミング、ラ
ベリング、などを含む）製品１８は、サプライチェーン２２に入ることが可能であり、最
終的には、その製品１８をさらに消費者に流通させる診療所または薬局４０８に到達する
。製品１８は、それ自体に、署名されたＲＦＩＤタグ２０をつけられている。上記署名は
、サプライチェーン２０における様々な段階や販売時点でタグ２０から読み取られて検証
される。よって、診療所または薬局４０８は、リーダ製造業者４１０にプログラムされて
供給されたＲＦＩＤリーダ１４を保有する。上述したとおり、署名されたＲＦＩＤタグ２
０の検証には、最新の検証鍵を保有していることが必要である。この検証鍵は、中央ＫＭ
Ｓ４００により、配布され、更新され、追跡され、あるいは、管理されている。ＫＭＳ４
００は、鍵投入制御部（key inject controllers）４２２を利用してもよい。これにより
、署名されたタグ２０の数、プログラムされたリーダ１４の数、および、配置済みリーダ
１４の数を追跡できる。なお、配置済みリーダ１４は、リーダ１４は、収益を収集するた
めに、ならびに、製品１８の流通およびその中身の秘密を保護するために更新される。Ｋ
ＭＳ４００は、制御された信頼できる方法にて、配置されているリーダ１４に、鍵や関連
情報を配布するのに用いられる。これにより、タグ２０のＥＣＰＶ署名４１６は、確実に
、「権限の有る」リーダ１４によってのみ、認証されるようになる。例えば、権限のない
リーダが、薬品ＩＤコード５４またはその他機密情報（あるいは、そうでなくてもＲＦＩ
Ｄタグ２０のパッシブタイプメモリのＥＣＰＶ署名に隠された情報）を取得することを防
ぐことができる。

図１１に示されるように、本例の薬品製造業者４０２で実施される製造工程は、一部に
、ＲＦＩＤタグのプログラミング段階（programming stage）４０４、および、薬剤製品
のラベリング段階（labelingstage）４０６を含む。薬剤製品１８は、ラベル１９を付与
されると間もなく、妥当な場合、サプライチェーンに入り、最終的には、診療所または薬
局４０８にたどり着く。そして、そこから、上述したとおり、製品１８は、消費者へ流通
する（販売される）。

タグプロブラミング段階４０４は、一般的には、プログラムされていない（好ましくは
、前もって焼き付けられた通し番号、または、ＵＩＤを含む）ＲＦＩＤタグ２０を取得ま
たは受信する。上記ＲＦＩＤタグ２０は、ＲＦＩＤプログラマ４１４を用いて、例えば、
図５に示されるＥＰＣグローバルコードなどの製品ＩＤコードなどを含むようにプログラ
ムされる。本例では、例えば、ＥＣＰＶ署名などのデジタル署名４１６は、ＲＦＩＤプロ
グラマ４１４によって、タグ２０に書き込まれる。ＲＦＩＤプログラマ４１４は、インタ
フェースを有し、鍵投入システム４１７ａによって、少なくとも部分的に制御されること
が望ましい。鍵投入システム４１７ａは、署名エージェント４１９ａと、鍵投入サーバ（
key injectserver）４１８ａ（本例においては、プログラミング段階４０４と同じ位置
にある）と、鍵投入制御部４２２ａ（通常、鍵投入サーバ４１８ａと安全に通信する外部
の主体である）とを含む。本例のＲＦＩＤプログラマ４１４は、タグ２０に署名４１６を
作成して書き込むために、署名エージェント４１９ａとの直接のインタフェースを有し、
必要な情報を取得する。

一般的に、鍵投入システム４１７は、装置の登録を離れて監視し、必要であれば、その
装置に不変で固有の情報の投入量を測る（meter）システムである。鍵投入システム４１
７の記述一式は、同時係属中の米国特許出願番号１１／４５０，４１８（出願日：２００
６年６月１２日）にあり、その内容を参照することで本明細書に組み込まれる。本例にお
いて、制御部４２２ａは、ＲＦＩＤプログラミング設備から離れているが、薬品を製造す
る会社の管理下にあることが好ましいコンピュータシステムである。

鍵投入サーバ４１８ａ、署名エージェント４１９ａ、ＲＦＩＤプログラマ４１４は、同
じ場所、または、建物にあってもなくてもよい。鍵投入システム４１７ａの構成要素につ
いて、内部および／または外部に接続するネットワーク上に、安全な接続を確立すること
が好ましい。署名エージェント４１９ａは、好ましくはハードウェアのセキュリティモジ
ュールにおいて、データ記憶装置４２０を備えている。このデータ記憶装置４２０は、署
名エージェント４１９が、暗号化、復号化、および、署名などの暗号処理にかかわる機密
保護の動作を行うため、および、機密データを保存するために使う、保護された装置であ
る。

記憶装置４２０は、各製品タイプに対する（例えば、各薬品に対する）鍵対（ｗ_ｊ，Ｗ
_ｊ）を保存する。本例では、薬品製造業者４０２は、５つ（５）の異なる製品について、
署名４１６を書き込む責任がある。よって、図１１に示されるように５つの鍵対を保存す
る。データ記憶装置４２０は、同じ施設の複数の製品ライン上または異なる建物に配置さ
れる、複数のＲＦＩＤプログラマ４１４からのアクセスを受けることが可能であると解さ
れる。よって、製造工程の物流管理に応じて、いくつの鍵投入システム４１７ａ、データ
記憶装置４２０、および、ＲＦＩＤプログラマ４１４が使われてもよい。ここでは、話を
単純にするため、１つの施設内における５つの製品ラインを例に説明する。本例では、製
品に適したいずれかの鍵対（ｗ_ｊ，Ｗ_ｊ）を使って署名４１６を書き込むように構成され
た１つのＲＦＩＤプログラマ４１４を備えている共通鍵投入システム４１７を利用する。
鍵投入システム４１７ａは、単に鍵を配布する方法の１つであり、ＫＭＳ４００がそのよ
うな工程を、監視し、制御する別の構成を用いてもよいものと理解される。よって、ＫＭ
Ｓ４００は、一般的に、鍵を配布するための制御部と考えられ、ＲＦＩＤ認証システム全
体において含まれる様々な当事者と相互に作用するのに、適用可能なサブシステムならど
のようなものでも使うことができる。

署名４１６は、通し番号、製品１８に固有の製品ＩＤコード５４、および、他のサプラ
イチェーン２２特有のメタデータを用いて、また、その製品１８用の秘密鍵を用いて、タ
グ２０に署名することにより生成される。署名４１６は、上述したとおり、タグ２０に書
き込まれるＥＣＰＶ署名であることが好ましい。

図１１から分かるように、ラベリング段階４０６では、署名４１６を含む、プログラム
されたＲＦＩＤタグ２０をラベル１９に付け、さらに、ラベル１９を製品１８に付ける。
ラベリング段階４０６がＲＦＩＤプログラミング段階４０４に統合されていてもよいし、
同様に、両者が同じ施設にあってもよい。この場合も、製造工程の性質は、製品１８、産
業における必要条件などに依存する。そして、図１１は単に説明用の一構成である。本例
では、ラベリング機（図示せず）を使用してもよいし、望まれる場合、または、署名がラ
ベリング段階４０６で付加される場合、ラベリング機は、鍵投入システム４１７ａとのイ
ンタフェースを有していてもよい。

製品１８はラベルをつけられると、輸送、入庫、流通などの工程を含むサプライチェー
ン２２に入れられる。以下で述べられるとおり、追加の署名４１６を、タグ２０に追加す
ることも可能である。および／または、署名４１６は、サプライチェーンのどの段階でも
（または、全ての段階で）ＲＦＩＤリーダ１４によって検証されてもよい。

製品１８（ここでは薬品）は、最終的には、１つ以上の診療所または薬局４０８に到達
する。診療所または薬局４０８は、その後の薬品１８の消費者への流通を担うものであり
、図１４に詳細が示される。各診療所または薬局４０８は、更新された鍵対を含むリーダ
１４を備える。更新された鍵対は、ローカルに保存されている。好ましくは安全なハード
ウェア、つまり、データ記憶装置４２６に保存されている。図２において概略的に示すよ
うに、リーダ１４は、各自の鍵対を保存している。この例では、リーダ１４は、リーダ１
であり、鍵対（ｚ_１，Ｚ_１）、対応する証明書Ｃ_ＶＥＲ１のコピー、ＣＡの証明書Ｃ_ＣＡ
のコピー、および、リーダ１が使うことを許可されている検証鍵（例えば、鍵Ｗ_１−５）
を保管している。検証鍵は、以下で説明されるように、ＫＭＳ４００によって、条件付で
付与される。

各リーダ１４は、図１２に示すとおり、鍵投入システム４１７を使うリーダ製造業者４
１０にてプログラムされる。リーダ製造業者４１０は、鍵対（ｚ_ｉ，Ｚ_ｉ）を生成し、識
別目的で装置識別子Ｄｅｖ_ｉを各リーダ１４に割り当てるために、鍵投入システム４１７
を使う。リーダ製造業者４１０は、ＫＭＳ４００用に装置識別子を記録したデータベース
４２４を備えている。リーダ製造業者のリーダ／プログラマ４２１は、別の鍵投入エージ
ェント４１９ｂとのインタフェースを有している。そして、上記鍵投入エージェント４１
９ｂは、リーダ１４のプログラミングをたどるために、別の鍵投入エージェント４１８ｂ
と通信する。このように、各リーダ１４は新しい鍵対を付与されているので、鍵投入サー
バ４１８ｂは、別の投入制御部４２２ｂを介して、ＫＭＳ４００に新しい鍵を折り返し伝
えることができ、その様な業務の利益を追跡することができる。

図１３に示されるように、ＫＭＳ４００は、ＣＡ４２９、認証サーバ４２８、および、
条件付アクセスデータベース４３０を備え、領域内のリーダ１４が、署名端末１６用に更
新された証明書を取得できるようにする。その後、これらの証明書は、リーダ１４によっ
て、署名端末１６の鍵投入エージェント４１８により生成されるデジタル署名４１６を検
証するために使われる。

署名端末１６用の新しい鍵対（ｗ_ｊ，Ｗ_ｊ）は、いくつかの方法で生成できる。例えば
、鍵対は、承認された作業者により、安全な環境下で生成されてもよい。そして、必要に
応じて、鍵対を、署名端末１６にアップロードしてもよい。他の実施形態においては、鍵
対は署名エージェント４１９、または、鍵投入サーバ４１８によって、自動的に生成され
てもよい。また他の実施形態では、鍵対は、鍵投入制御部４２２、または、ＫＭＳ４００
によって（すなわち、離れた場所で）生成されてもよい。そして、その鍵対は、安全に署
名端末１６に（すなわち、鍵投入サーバ４１８、および、エージェント４１９を介して）
送付、または、アップロードされてもよい。新しい鍵対（ｗ_ｊ，Ｗ_ｊ）は、新しい署名端
末１６が配置される毎に、または、既存の署名端末１６が（例えば、異なる製造ライン用
の）複数の鍵を使うことが所望される場合に、必要となる。署名端末１６が、新しい鍵対
を生成すると、秘密鍵とともに署名された公開鍵を含む証明書の要求が作成される。証明
書の要求は、ＫＭＳ４００に折り返し送信される。本例において、証明書の要求の送付は
鍵投入制御部４２２ａを通して行われる。鍵投入制御部４２２ａを使うことによって、Ｋ
ＭＳ４００が、鍵情報を最新の状態に保つことができるのみならず、正式な合意のない新
しい製造ラインを造る不正な試みを抑制することができる。よって、ＫＭＳ４００は、正
当に手続きされた各製造ラインの、署名された各タグ２０に対応する収益を追跡し、取得
することができる。

また、ＫＭＳ４００は、別の鍵投入制御部４２２ｂを使って、プログラムされたリーダ
１４の数を追跡できる。このように、ＫＭＳ４００は、署名端末１６によって署名された
署名４１６を検証することができる（また、許可を有する）全てのリーダ１４を確実に認
識できる。これによって、署名４１６の復元可能な内容の少なくとも一部が機密、または
、秘密の情報である場合、ＫＭＳ４００は全システムの安全性および秘密性をより確実に
できる。

同様に、ＫＭＳ４００は、タグ２０がサプライチェーン２２を通る際に起こる、各署名
検証、または、追加の署名書き込み動作を追跡できる。よって、ＫＭＳ４００は適切なエ
ンティティに鍵を安全に配布するだけでなく、鍵配布サービスにおける収益点を確認でき
る。例えば、ＫＭＳ４００は、署名されたタグ２０の数、および、プログラムされたリー
ダ１４の数を追跡し、装置ごとまたはタグごとの使用料を収集できる。また、ＫＭＳ４０
０は、診療所または薬局４０８でのリーダの使用についても追跡し、更新された鍵を持つ
配置されたリーダ１４を同期させることについての、月額料金または定額サービス料金を
回収してもよい。そして、診療所または薬局４０８、および、製造業者４０２は、その消
費者、および／または、その取引先に安全性および秘密性を提供できる。

次に、図１５に基づいて、署名端末１６用の新しい鍵を生成し、タグ２０に署名をする
ための工程を概略的に示す。上述したとおり、新しい鍵対（ｗ_ｊ，Ｗ_ｊ）を、安全な環境
で生成し、署名エージェント４１９ａに手動でロードできる。もしくは、新しい鍵対（ｗ
_ｊ，Ｗ_ｊ）を、ＫＭＳ４００および／または鍵投入システム４１７ａによって生成し、ロ
ードすることができる。上記新しい鍵対が生成されて署名端末１６（例えば、製造業者４
０２）にロードされると、鍵エージェント４１９ａは証明書の要求を生成して、例えば、
鍵投入システム４１７ａを通して、ＫＭＳ４００に送信する。なお、図１０から図１４ま
でに示されるシステムでは、署名端末１６、および、リーダ１４が常時ネットワーク上に
ある必要はない。よって証明書の要求は、例えば、ｅメール、または、その他の通信形式
で、ＫＭＳ４００に対する証明書追加の取引上の要求と共に、鍵投入サーバ４１８ａによ
って、後程に、ＣＡ４２９に送付されてもよい。

取引上の要求は、通常、ＫＭＳ４００と製造業者４０２との取引関係のパラメータを含
む。例えば、署名生成の際には現行の有効な鍵によって更新された状態に製造業者４０２
を維持することに対する、署名ごとの料金（ＫＭＳ４００が回収する料金）に関する合意
などが考えられる。また、製造環境の性質、製品１８、出来高、単価などによって、定額
月料金や単発料金などの別の合意がなされていてもよい。

ＫＭＳ４００により、取引上の合意が処理されると、ＫＭＳ４００は生成された鍵対に
対応する証明書Ｃ_{ＳＩＧＮｊ}を発行し、返信する。証明書は、その証明書を受ける権利が
あるリーダ１４のリストと共に、認証サーバ４２８におかれる。よって、取引上の要求に
も、通常、サプライチェーン２２中の好ましい、または、必須の流通者および／または通
信者に関する詳細が含まれる。これにより、ＫＭＳ４００は、リーダ１４に対する許可を
追跡し、それに応じてそれらのリーダ１４の鍵を更新できる。また、証明書Ｃ_{ＳＩＧＮｊ}
は、上述したとおり、今後参照するために、署名端末１６によっても保存される。なお、
署名端末１６は、通常の動作において、必ずしも証明書を使うわけではない。

署名エージェント４１９ａに、１つ以上の製品ラインの１つ以上の製品１８に対応する
、１つ以上の鍵が供給されると、タグ２０はプログラミング段階４０４で署名される。鍵
投入システム４１７ａは、署名されたタグ２０の数を制限するために、信用取引量（cred
it pool）を測る（meter）のに用いられてもよい。あるいは、その代わりに、鍵投入シス
テム４１７ａは、安全な報告処理を用いることによって署名されたタグ２０の数の簡単な
追跡を行ってもよい。例えば、図１５に示されるように、タグ２０に署名をした後、署名
エージェント４１９ａは、署名サーバ４１８ａに、タグ２０が署名されたことを示す報告
を返す。報告は、特定の実行や移動時に、各タグ２０について繰り返される。それから、
署名エージェント４１９ａは、次の命令、更新、または、タグ２０のバッチ処理を待つ。
それから、サーバ４１８ａは、適切な時に、鍵投入制御部４２２ａを通して、ＫＭＳ４０
０に、署名されたタグの合計数を報告してもよい。あるいは、署名エージェント４１９ａ
は、署名されたタグの数を追跡し、サーバ４１８ａに合計数を報告し、さらにサーバ４１
８ａが制御部４２２ａを通してＫＭＳ４００に折り返し報告をするようにしてもよい。鍵
投入システム４１７ａは、タグの署名を追跡できるだけでなく、特定の時間内に、および
／または、特定の製造業者４０２、または、製造ライン用などについて、署名されたタグ
２０の数を制限するために、信用取引量（credit pool）を測ることもできる。

次に、図１６に基づいて、リーダ１４の登録工程を示す。まず、リーダ製造業者４１０
にて、リーダ１４が、リーダの鍵対（ｚ_ｉ，Ｚ_ｉ）の作成も含めて、製造される。リーダ
１４は、証明書の要求を生成し、それを、鍵投入システム４１７ｂを介して、ＫＭＳ４０
０に送信する。そして、リーダ１４は、対応する証明書Ｃ_ＶＥＲｉを発行してもらう。そ
れから、リーダ１４は、診療所または薬局４０８、または、サプライチェーン２２の中の
特定の段階に配置される。リーダ１４は配置されると、登録を要求するために、鍵投入シ
ステム４１７ｂを通して、ＫＭＳ４００に接続される。ＫＭＳ４００は、もしあれば、リ
ーダ１４の特定の所持者に権利を与えられている鍵がどれかを判定し、要求の正当性を検
証する。正当性が確認された場合、ＫＭＳ４００は、リーダ１４に一対の許可を与え、そ
れを記録する。ＫＭＳ４００は、対応する検証鍵Ｗ_ｊと共に、これらの許可を示すものを
、リーダ１４に送る。この時点で、メタデータが添付されてもよい。それから、リーダ１
４は、好ましくは、ハードウェアセキュリティモジュール（ＨＳＭ）の中に、安全に鍵を
保存し、ＫＭＳ４００に鍵の受領を知らせる。その後、製品１８が売られる際に、リーダ
１４は、タグ２０上の署名４１６を検証するために、上記許可に従い、検証鍵を使っても
よい。

その間、リーダ１４は、所定の時間が経過していくつかの鍵が失効している場合があっ
たり、新しい製品１８の検証が必要な場合があったりするので、ＫＭＳ４００からの更新
を待つ。ＫＭＳ４００は、署名端末１６（例えば、製造業者４０２）から取得されるフィ
ードバックに基づいて、また、製造情報、秘密問題などに基づいて、リーダ１４を更新で
きる。

次に、図１７に基づいて、リーダ１４の更新処理が示される。ＫＭＳ４００は、まず、
証明書の取り消し、製品の期限切れ、および、製品１８の有効性とそれに対応する署名４
１６を検証するのに使われる鍵Ｗ_ｊの有効性とに影響するその他情報を取得または収集す
る。この情報は、特定のリーダ１４に割り当てられた許可に関するローカルに保存された
情報と比較され、各リーダ１４の更新の準備が行われる。ＫＭＳ４００は、接続可能な場
合（もしくは、ポーリングまたは他の予定されたルーチンを使って）、リーダ１４に接続
し、更新情報を送信する。それから、ＫＭＳ４００は、リーダ１４が更新されたという通
知を待ち、その後、次の更新が要求される、および／または、可能になるまで、接続を断
つ。

ＫＭＳ４００は、半オンライン状態で作動することができ、よって、リーダ１４、およ
び、署名端末１６は常にオンライン状態にある専用接続を必要としないことが分かる。Ｋ
ＭＳ４００は、必要な時に更新作業をすることができる。または、接続の確立を必要とす
る予定された更新をすることができる。可能であれば、製造環境、サプライチェーン２２
、および、流通路経路の性質によって、完全にオンライン状態のシステム、および／また
は、閉ループのシステムが、１つの主体の中で、使われてもよい。

図１８に、ＫＭＳ４００が、最新の鍵を維持することの対価としての、各回の利用料金
および定額料金を追跡し、回収ことができるようにする、典型的な利益フローを示す。例
えば、署名側では、鍵投入サーバ４１８ａは、書き込まれる署名の数を追跡し、その数を
制御部４２２ａに報告するのに用いられてもよい。さらに、必要であれば、鍵投入サーバ
４１８ａは、更なる署名の書き込みなどが可能であるかを判断するのに用いられてもよい
。（計量（metering））するため、および、さらなる信用取引額（credit）に関して報告
をＫＭＳ４００に返すために、鍵投入サーバ４１８ａが用いられてもよい。あるいは、特
定の製造業者４０２から回収すべき収益を単に報告するために鍵投入サーバ４１８ａが使
われてもよい。サーバ４１８ａは、統合された収益レポートをＫＭＳ４００に対して作成
するために、複数の製品ラインの複数の署名エージェント４１９ａを追跡するのに用いる
ことが可能である。制御部４２２ａは、制御部４２２の動作を（例えば、ログレポートを
使って）監視しているＫＭＳ４００と共に、与信の管理および信用取引額の更新の責任を
担う（および、ＫＭＳ４００にこの情報を伝える）ことが望ましい。しかし、ＫＭＳ４０
０は、適切であれば、更なる与信額を認めてもよい。そして、ＫＭＳ４００は、接続が確
立されている間に更新の準備をし、書き込まれた署名４１６に対する収益を製造業者４０
２から直接回収することもできる。上述したとおり、収益は、対応する取引上の必要条件
や取り決めによって、決められる。例えば、ＫＭＳ４００は、前もって所定の数の署名４
１６に対する費用を回収し、その後、個別の署名に対して、追加収益を取得してもよい。

リーダの製造業者４１０に対して、ＫＭＳ４００は、製造されるリーダ１４毎に費用請
求してもよい。リーダ１４は、費用請求および追跡の必要性のために、鍵投入サーバ４１
８ｂおよび制御部４２２ｂによって、追跡され、ＫＭＳ４００に折り返し報告される。リ
ーダ１４が配置されると、ＫＭＳ４００は、正規のサービス料金と引き換えに、鍵を更新
することが望ましい。各リーダによる各読み取りを追跡することは、読み取りの失敗など
があるため、案外難しいが、ＫＭＳ４００は、読み取りごとにも料金を請求することがで
きることは解される。また、同様の収益の流れが、他のエンティティが関与する性質によ
り、サプライチェーン２２におけるほかの様々な段階を通じて追跡され、取得されること
が可能なことがわかる。

〔複数の署名主による署名の集約（Aggregate Signatures for Multiple Signers）〕
署名端末の数が多いまたは署名の数も多い、かつ、署名を保存するためのスペースの量
が限られているまたは確保困難な（例えば、ＲＦＩＤタグ２０）場合、全署名の全てを含
めたサイズには高い費用がかかる可能性がある。以下の署名方式は、１または複数の署名
要素を集約することにより、複数署名の大きさを減少させる。以下の方式は、２つ以上の
署名を圧縮する従来の複数署名方式を改良したものである。

以下に示される署名方式は、ここに説明され、例示されるように、ＲＦＩＤ署名方式に
おいて、複数の署名手段から提供されたものをＲＦＩＤ署名方式に組み込むのに特に適し
ているが、どのような環境に対しても適用可能であると理解できる。

ある１つの実施においては、以下の集約署名方式（aggregate signature scheme）を、
複数の署名端末に（例えば、薬剤サプライチェーンにおけるＲＦＩＤタグ２０に）採用す
ることができる。

従来、集約署名は、バイリニアペアリング（bilinear pairing）を用いたデジタル署名
アルゴリズムに基づいて提案されてきた。アルゴリズムは、従来の署名方式に２つの追加
の動作を備えた集約署名方式を定義する。第１の動作で、公開鍵Ｕ_１、．．．、Ｕ_ｔを持
つ、ｔ人のユーザによって署名されたメッセージｍ_１、ｍ_２、．．．、ｍ_ｔの署名セット
ｓ_１、ｓ_２、．．．、ｓ_ｔを取得し、これらを１つの圧縮された署名ｓに集約する。第２
の動作で、メッセージｍ_１、ｍ_２、．．．、ｍ_ｔ、および、ユーザの公開鍵Ｕ_１、．．．
、Ｕ_ｔが与えられると、集約署名ｓを検証する。対応するメッセージおよびユーザごとに
、すべてのｓｉの正当性が認められたら、そしてその場合のみ、署名ｓの正当性が認めら
れる。

以下は、特に、ＥＣＰＶＳ署名に好適に使えるが、他のエルガマル（EIGamal）署名に
も同じく適用でき、また、同様に、以下に示されるようにＥＣＤＳＡのような別の方式に
も、利用できる。

ＥＣＰＶＳおよびＥＣＤＳＡ署名方式にを参照にする場合、上記の専門用語が、一貫性
を保つために繰り返して使われる。

上述の各例にしたがって、それぞれメッセージＭを署名するＴ個の署名端末１６がある
ものとする。単純化のため、全署名端末のＭが同じであるとする。そして、ＥＣＰＶＳを
使って署名される場合、復元可能な部分Ｈ（例えば、製品ＩＤ）、および、可視部Ｖ（例
えば、ＵＩＤ）も同じであるとする。ある場合において、Ｖは、各署名端末ｊ、例えば、
Ｖ_ｊごとに異なるものと理解される。また、上記に代えて、以下においては、署名端末ご
とに異なる復元可能なメッセージＨ_ｊを署名することも可能であると考えられる。

以下には、半集約署名方式（semi-aggregate signature scheme）、および、完全集約
署名方式（fully-aggregatesignature scheme）の、２種類の集約方式について示す。半
集約署名方式は、元のサイズの２／３に署名を圧縮できることが分かっている。完全集約
署名方式は、いくつかの署名端末１６があるにもかかわらず、圧縮された集約署名が、１
つの署名サイズであることから、そのように呼ばれている。圧縮率は、Ｔ個の署名端末が
ある場合、Ｔ倍である。よって、完全集約方式は、多くの署名端末がある場合に、非常に
高い圧縮率を達成することができる。

完全集約は、半集約より、優れた圧縮を行うが、集約署名を作成するのに、各署名端末
の協力が必要である。よって、署名端末が、異なる場所にある場合には、適さない場合が
ある。さらに、例えば、当事者が様々な時間に署名をする場合といった別の状況において
は、完全集約署名は不可能である場合がある。しかし、半集約署名は、以下のように、非
同期の署名を可能にする。よって、半集約署名を、必要に応じて、完全集約に代えて採用
することができる。

〔半集約ＥＣＰＶＳ（Semi-Aggregate ECPVS）〕
Ｔ個の署名端末のＥＣＰＶＳを用いた半集約署名方式は、第１の署名端末、すなわち、
署名端末１が、ｃ_１内の隠される部分Ｈを暗号化することによって、従来のＥＣＰＶＳ署
名（ｃ_１，ｓ_１）を算出することにより始まる。次に、署名端末２は、Ｈを暗号化せずに
、ｃ_２を算出するときにｃ_１を暗号化する。そして、別の要素ｓ_２を、通常の方法で算出
して、更新された署名（ｃ_２，ｓ_１，ｓ_２）を算出する。これが、署名端末Ｔが、ｃ_Ｔを
計算する時にｃ_Ｔ−１を暗号化するまで、各署名端末について繰り返される。そして、半
集約署名は、（ｃ_Ｔ，ｓ_１，．．．ｓ_Ｔ）となる。言い換えれば、各署名端末は、先の“
ｃ”要素を暗号化し、さらに、更新された“ｃ”要素を使って、次の“ｓ”要素を生成す
る。

半集約ＥＣＰＶＳ署名を検証するために、検証装置１４（例、ＲＦＩＤリーダ）は、ま
ず、要素（ｃ_Ｔ，ｓ_Ｔ）をＥＣＰＶＳ検証することによって、ｃ_Ｔ−１を復元して、ｃ_Ｔ
からｃ_Ｔ−１を復号する。次に、検証装置は、（ｃ_Ｔ−１，ｓ_Ｔ−１）からｃ_Ｔ−２を復
元する。これがＨの表記Ｈ’が復元されるまで繰り返される。それから、Ｈ’は、冗長性
などの特定の特徴についてチェックされる。もし、その特徴が存在するのであれば、メッ
セージＭはＨ’とＶとを使って再構築される。

半集約方法は、２つの理由のためにそのように呼ばれる。第１に、中間暗号文ｃ_１，．
．．，ｃ_Ｔ−１が、最終暗号文ｃ_Ｔに含まれる必要がない。第２に、検証装置１４は、全
ての暗号文が復号されるまで、中間署名の、承認または拒絶を引き延ばす。例えば、署名
端末２から署名端末Ｔまでが、冗長性を追加する必要はない。よって、追加の署名端末は
、値ｓ_２，．．．，ｓ_Ｔを追加することによって、単にメッセージの拡張を行うだけであ
る。

さらに、半集約署名方式を説明するために、図１９、図２０を参照しながら、３個の署
名端末に対する例を、以下に示す。以下の例は、薬剤サプライチェーンに、特に適用され
る。薬剤サプライチェーンは、サプライチェーン２２の中にある３個の署名端末１６を含
み、各署名端末１６は、物体１８（図１も参照）に付けられたＲＦＩＤタグ２０に加えら
れた署名に、それぞれが寄与する。半集約署名方式は、どんな環境においても複数の署名
を提供するのに用いられ、ＲＦＩＤシステムに限定されない。

図１９に示されるように、署名端末１は、一時的な鍵対（ephemeral key pair）の（ｋ
_１，Ｑ_１）を生成する。そして、上述したとおり、暗号鍵Ｘ_１＝ＫＤＦ（Ｑ_１）を生成す
る。そして、第１の署名端末ｃ_１についての第１の署名要素が、鍵Ｘ_１を用いてメッセー
ジＭの復元可能な部分Ｈを暗号化することによって算出される。ここでは、Ｈには、後の
検証のために、十分な冗長性を確実に存在させる。そして、メッセージＭの可視部Ｖを用
いて、中間要素ｈ_１が、ハッシュ関数（例えば、ＳＨＡ１）を使って算出され、そして、
整数ｅ_１に変換される。この整数ｅ_１は、署名端末１の秘密鍵ｗ_１と一時鍵ｋ_１と共に、
第１の署名端末についての第２の署名要素ｓ_１を生成するために用いられる。本例におい
ては、その後、要素（ｃ_１，ｓ_１）をもつ署名が、ＥＣＰＶＳで通常どおりに、ＲＦＩＤ
タグ２０に書き込まれる。

それから、署名端末２、つまり、第２の署名端末は、別の署名を追加するのではなくて
、更新された半集約署名を作成するのに寄与する。この例においては、署名端末２は、サ
プライチェーンにおける別の地点にある。署名端末２は、署名端末１と同様に、一時鍵対
（ｋ_２，Ｑ_２）と暗号鍵Ｘ_２＝ＫＤＦ（Ｑ_１）を生成する。しかし、この段階では、署名
端末２は、Ｘ_２を使って、既存の署名要素ｃ_１を暗号化して、署名要素ｃ_２を生成する。
中間署名要素ｈ_２、整数ｅ_２、および、署名要素ｓ_２は、上述のように算出されるが、結
果として更新された署名は、この時点で、要素（ｃ_２，ｓ_１，ｓ_２）のセットを含む。そ
のため、署名要素ｃ_１は、ｃ_２に暗号化されて、“ｓ”要素（すなわち、この段階ではｓ
_１とｓ_２）が、更新された署名の中に保持される。

本例で、最終署名段階の第３の署名端末、すなわち、署名端末３もまた、現段階でＲＦ
ＩＤタグ２０上の、（ｃ_２，ｓ_１，ｓ_２）を含む半集約署名に寄与する。先の署名端末１
６と同様に、署名端末３は、それ自身の暗号鍵（この場合はｋ_３）を生成する。その後、
更新された“ｃ”の署名要素ｃ_３を生成するために、ｋ_３を使って、署名要素ｃ_２を暗号
化する。中間要素ｈ_３、整数ｅ_３、および、要素ｓ_３が、上述したとおり算出され、この
ようにして更新された（そして、本例においては最終の）署名は、要素（ｃ_３，ｓ_１，ｓ
_２，ｓ_３）を含む。

各段階では、先の署名端末１６の“ｃ”要素を組み込まれた新しい署名が、半集約署名
の先の形式に上書きされる。よって、半集約署名（ｃ_Ｔ，ｓ_１，．．．ｓ_Ｔ）は、ＲＦＩ
Ｄタグ２０に個々の署名（（ｃ_１，ｓ_１），．．．，（ｃ_Ｔ，ｓ_Ｔ））を書き込む場合よ
りも小さくなる。

今度は、図２０を参照にすると、半集約署名の検証は、通常、各署名段階に対応する段
階を含み、本例においては、ＲＦＩＤタグは、要素（ｃ_３，ｓ_１，ｓ_２，ｓ_３）とメッセ
ージＭの可視部Ｖ（例えば、ＵＩＤ）とをもった署名を含む。

段階１では、検証装置１４は、要素ｃ_３と可視部Ｖを用いてｈ_３’を算出し、ｈ_３’を
整数ｅ_３’に変換し、ｓ_３およびｅ_３’と署名端末３の公開鍵Ｗ_３とを用いて、Ｑ_３’算
出する。それから、検証装置１４は、同じＫＤＦをＱ_３’に適用してＸ_３’を生成する。
その後、検証装置１４は、Ｘ_３’と、復号補関数（例えば、図２０で“ＤＥＣ”と表記さ
れる関数）とを使って、ｃ_３を復号することにより、ｃ_２を取得する。

段階２では、検証装置は、ｃ_２を取得したことで、要素ｃ_２と可視部Ｖとを用いて、ｈ
_２’を算出する。そして、検証装置は、ｈ_２’を整数ｅ_２’に変換し、ｓ_２とｅ_２’と署
名端末２の公開鍵Ｗ_２とを用いてＱ_２’を算出する。そして、同じＫＤＦをＱ_２’に適用
してＸ_２’を生成する。それから、検証装置は、Ｘ_２’と復号化補関数とを用いてｃ_２を
復号し、ｃ_１を取得する。

段階３では、検証装置は、要素ｃ_１と可視部Ｖとを用いてｈ_１’を算出し、ｈ_１’を整
数ｅ_１’に変換する。そして、検証装置は、ｓ_１、ｅ_１’、および、署名端末１の公開鍵
Ｗ_１を用いて、Ｑ_１’を算出する。それから、検証装置は、同じＫＤＦをＱ_１’に適用し
てＸ_１’を生成する。ｃ_１は、メッセージＨの復元可能な部分を暗号化することによって
生成されたので、Ｈの表記であるビット列Ｈ’は、Ｘ_１’を用いてｃ_１を復号することに
よって取得される。それから、段階４で、検証装置１４は、予測される特徴（本例におい
てはＨ’の冗長性など）をチェックする。もし、十分にその特徴があれば、Ｈ’を復元可
能な部分Ｈとして受け入れ、例えば、段階５で、Ｈ’とＶとを結合することによってメッ
セージＭを再構築することができる。その後、検証装置１４は、各署名端末が、要素（Ｈ
，Ｖ）で示されるメッセージＭを署名した、と結論づけてもよい。

なお、本例において、各署名端末１６は１つの可視部Ｖを処理するが、その代わりに、
上記可視部は、署名端末１６ごとに異なるＶ_ｉであってもよい。この場合においては、各
中間要素ｈ’は、それぞれの可視部Ｖ_ｉを使って算出される。そして、検証装置１４は、
同じそれぞれの可視部Ｖ_ｉを用いて、各検証段階を実施する。同一の可視部Ｖを用いた上
述の例は、単純化のために示されたものである。

上記半集約署名方法において、第１署名端末１６（例、署名端末１）の後に続く、８０
ビットの安全性レベルの追加の各署名端末１６は、１６０ビット程度のメッセージ拡張に
寄与することが分かる。この１６０ビット程度のメッセージ拡張は、８０ビットの安全性
レベルでは、ｎおよびｓ_ｉのビットサイズである。１２８ビットの安全性では、署名端末
ごとの比較的少ないメッセージ拡張は、２５６ビット程度である。したがって、上記半集
約署名方法は、複数の署名手段に署名に寄与させる場合に特に適している。また、これに
より、検証装置は、サプライチェーンにおいて予定されている参加者によってＲＦＩＤタ
グなどが取り扱われたことを保証することができる。半集約署名方式は、記憶領域、帯域
、または、その両方が確保しにくいどんな環境にも、同様の利点を提供する。

〔半集約署名の変形例（Semi-Aggregate Signatures - Variations）〕
上述の半集約方法では変形が可能である。例えば、署名端末は、各署名段階で少量の冗
長性を追加することも可能である。これは、最低限の量（例、１バイト）の平文への埋め
込みを通常必要とする検証過程において修正が必要にならないことを確実にするために行
われる。この変形例は、対称暗号方式において、どんなバイト長の平文をも用いることが
でき、暗号文が平文より長くならないようにする場合に適切である。

別の変形例では、中間平文が先の署名端末の“ｓ”要素を組み込む。この変形例におい
て、最終署名は、（ｃ_Ｔ，ｓ_Ｔ）の形式である。そして、検証装置１４は、ｃ_Ｔなどから
、ｃ_Ｔ−１やｓ_Ｔ−１を復元する。半集約署名のこの形式では要素は少ないが、ｃ_Ｔ−２
およびｓ_Ｔ−２などの暗号である暗号文ｃ_Ｔ自体が、ｃ_Ｔ−１やｓ_Ｔ−１の暗号であるた
め、必ずしも、長さが短くなるわけではない。ｃ_Ｔの長さは最短でも、Ｈの長さに、ｓ_１
，．．．，ｓ_Ｔの長さの合計が加算されたものになると予想され、それは、おおよそ、半
集約署名（ｃ_Ｔ，ｓ_１，．．．ｓ_Ｔ）の第１の形式と同じ長さである。

別の変形例においては、中間平文が、先の暗号文を含まない、先の“ｓ”の値である。
この変形例においては、最後の署名は、（ｃ_１，．．．，ｃ_Ｔ，ｓ_Ｔ）の形式である。こ
こでは、検証装置が、ｃ_Ｔなどからｓ_Ｔ−１を復元する。この場合もまた、署名長は、お
およそ、第１の形式（ｃ_１，ｓ_１，．．．，ｓ_Ｔ）と、同じとなると予想される。

半集約署名方式に関するこの変形例を更に示すために、サプライチェーン２２に３つの
署名端末１６が在る以下の例が、図２１および図２２を参照にして示される。また、以下
の例は、サプライチェーン２２中に、それぞれ物１８に付けられたＲＦＩＤタグ２０（図
１も参照）に加えられる署名に寄与する３つの署名端末１６を含む薬剤サプライチェーン
に、特に適用される。

図１９と同様に、図２１に示されるように、署名端末１は一時鍵対（ｋ_１，Ｑ_１）を生
成し、暗号鍵Ｘ_１＝ＫＤＦ（Ｑ_１）を算出する。それから、第１の署名要素ｃ_１が、メッ
セージＭの復元可能な部分Ｈを用いて算出され、後の検証用にＨの中に十分な冗長性が確
実に存在するようにする。メッセージＭの可視部Ｖを用いて、中間要素ｈ_１がハッシュ関
数（例、ＳＨＡ１）を用いて算出され、ｈ_１が整数ｅ_１に変換される。それから、整数ｅ
_１は、署名端末１の秘密鍵ｗ_１および鍵ｋ_１と共に、第２の署名要素ｓ_１を生成するため
に用いられる。この例においては、要素（ｃ_１，ｓ_１）を有する署名が、その後、ＲＦＩ
Ｄタグ２０に書き込まれる。

それから、既に述べたように、署名端末２は、一時鍵対（ｋ_２，Ｑ_２）を生成し、暗号
鍵Ｘ_２＝ＫＤＦ（Ｑ_２）算出することにより、半集約署名に寄与する。ただし、この変形
例では、署名端末２は、署名要素ｃ_２を生成するのに、Ｘ_２を使って、既存の署名要素ｓ
_１を暗号化する。中間署名要素ｈ_２、整数ｅ_２、および、署名要素ｓ_２は、通常通り算出
されるが、その結果の更新された署名は（ｃ_１，ｃ_２，ｓ_２）を含む。このように、署名
要素ｓ_１はｃ_２に暗号化されており、“ｃ”要素（すなわち、この段階ではｃ_１およびｃ
_２）は、上記署名より直接利用できるように保たれる。

それから、上述のように、署名端末３もまた、図２１に示されるように、結果としての
更新された署名（ｃ_１，ｃ_２，ｃ_３，ｓ_３）を作成することにより、半集約署名に寄与す
る。上で述べたのと同様に、署名端末３は、次の“ｃ”要素を生成する際、先の“ｓ”要
素を暗号化することによって署名を更新する。そして、各“ｃ”要素の貢献は、更新され
た状態で署名中に保たれる。

よって、この変形例における各段階で、先の署名端末１６の“ｓ”要素を組み込んだ新
しい署名が、半集約署名の先の形式に上書きされる。したがって、半集約署名（ｃ_１，．
．．ｃ_Ｔ，ｓ_Ｔ）は、個々の署名（（ｃ_１，ｓ_１），．．．，（ｃ_Ｔ，ｓ_Ｔ））をＲＦＩ
Ｄタグ２０に書き込む場合よりも小さい。

次に、図２２を参照すると、上述したとおり、半集約署名の検証には、各署名段階に応
じた段階が含まれる。そして、この例においては、ＲＦＩＤタグ２０は、要素（ｃ_１，ｃ
_２，ｃ_３，ｓ_３）とメッセージＭの可視部Ｖ（例、ＵＩＤ）とを有する署名を含む。

段階１において、検証装置１４は、要素ｃ_３、および、可視部Ｖを用いてｈ_３’を算出
し、ｈ_３’を整数ｅ_３’に変換し、ｓ_３、ｅ_３’および署名端末３の公開鍵Ｗ_３を用いて
Ｑ_３’を算出する。それから、検証装置１４は、同じＫＤＦをＱ_３’に適用して、Ｘ_３’
を生成する。その後、検証装置１４は、Ｘ_３’と、例えば、図２２で“ＤＥＣ”と表記さ
れる復号補関数とを用いてｃ_３を復号化することにより、ｓ_２を取得する。

検証装置は、ｓ_２を取得したので、段階２では、要素ｃ_２および、可視部Ｖを用いてｈ
_２’を算出し、ｈ_２’を整数ｅ_２’に変換する。それから、検証装置は、ｓ_２、ｅ_２’お
よび署名端末２の公開鍵Ｗ_２を用いて、Ｑ_２’を算出する。それから、同じＫＤＦをＱ_２
’に適用して、Ｘ_２’を生成する。そして、検証装置は、Ｘ_２’と暗号補関数とを用いて
ｃ_２を復号化することにより、ｓ_１を取得する。

段階３では、検証装置は、要素ｃ_１と可視部Ｖとを用いてｈ_１’を算出し、ｈ_１’を整
数ｅ_１’に変換する。そして、（段階２で復元された）ｓ_１と、ｅ_１’、および、署名端
末１の公開鍵Ｗ_１を用いて、Ｑ_１’を算出する。それから、検証装置は、同じＫＤＦをＱ
_１’に適用してＸ_１’を生成する。この変形例において、Ｘ_１’は先に復元されたｓ_１を
持つことによってのみ復元可能である。上述したとおり、ｃ_１はメッセージＨの復元可能
な部分を暗号化することによって生成されたので、Ｈの表記であるビット列Ｈ’は、Ｘ_１
’を用いてｃ_１を復号することにより取得される。それから、段階４で、検証装置１４は
、予測される特徴（本例においてはＨ’の冗長性など）をチェックする。もし、十分にそ
の特徴があれば、Ｈ’を復元可能な部分Ｈとして受け入れる。検証装置１４は、段階５で
、例えば、Ｈ’とＶとを結合することによって、メッセージＭを再構築することができる
。その後、検証装置１４は、各署名端末が、メッセージＭを署名した、と結論づけてもよ
い。

各署名端末１６に対して、復元可能な部分Ｈが、同じでない場合もある。例えば、復元
可能なメッセージの部分が、各署名端末１６に対してＨ_ｊであるとする。非集約方式の場
合、メッセージＨ_ｊに対して、各署名端末１６のＥＣＰＶＳ署名（ｃ_ｊ，ｓ_ｊ）があり、
メッセージＨ_ｊはｃ_ｊ中に符号化される。署名が集約される場合、各メッセージは符号化
される必要がある。

半集約署名を実現する第１のやり方では、個々に区別したメッセージＨ_ｊを、中間平文
に付加することにより、変更が可能である。中間平文は先の中間暗号文であったと解され
たため、先の暗号文は、現行の復元可能なメッセージの部分に連結させる（concatenated
）（または、別の方法で組み合わせる）ことができる。第１平文ＰＴ_１は、十分な冗長性
を保つために必要な埋め込みを持つＨ１である。そして、中間平文は、ＰＴ_２＝ｃ_１｜｜
Ｈ_２などにしたがって算出される。

例えば、署名端末３は、一時鍵対（ｋ_３，Ｑ_３）を生成し、Ｘ_３＝ＫＤＦ（Ｑ_３）を算
出し、さらに、

を計算し、それから、ｈ_３＝ＨＡＳＨ（ｃ_３｜｜Ｖ）を算出してｅ_３に変換し、ｓ_３＝ｅ
_３ｗ_３＋ｋ_３（ｍｏｄ ｎ）を計算する。この変形例において、最終的な集約署名は、（
ｃ_Ｔ，ｓ_１，．．．ｓ_Ｔ）の形式である。しかし、ｃ_Ｔの長さは、Ｈの長さだけではなく
、少なくとも個々に区別したメッセージＨ_１，Ｈ_２，．．．，Ｈ_Ｔをまとめた長さになる
。署名されたメッセージはより長くなっているが、メッセージの拡張は、上記と同様であ
る。これは、要素ｃ_Ｔが、署名される復元可能なメッセージの全長ほど長くないからであ
る。あるいは、メッセージの拡張は、主に“ｓ”によって生じるということができ、これ
は、個々に区別した復元可能な部分Ｈ_ｊまたは１つの復元可能な部分Ｈがあるか否かにか
かわらずいえることである。上述した変形例は、個々に区別した可視部Ｖ_ｊと同じく、個
々に区別した復元可能な部分Ｈ_ｊを用いた半集約署名の実施形態として、実現できると理
解される。

〔暗示的証明書と共に使われる半集約署名（Semi-Aggregate Signatures used with Im
plicitCertificates）〕
上述の半集約署名方法はまた、暗示的証明書（Implicit Certificates）と合わせて用
いることも可能である。アリスとボブとを通信者とする暗示的証明書に関して、アリスは
、ボブ、または、あるディレクトリより、ボブの暗示的証明書Ｃ_Ｂを取得する。この単一
の時点から、アリスはボブの公開鍵をＢ＝Ｈａｓｈ（Ｃ_Ｂ，Ｉ_Ｂ）＋Ｑ_ＣＡにしたがって
算出する。ここで、Ｉ_Ｂは、ボブ、証明機関（ＣＡ）、および、有効期間や鍵の使用法な
どの他の付属情報を識別する文字列であり、Ｑ_ＣＡは、識別されたＣＡの公開鍵である。
ここでアリスは、Ｂをボブの潜在的に認証された公共鍵として用いることができる。その
潜在的な性質は、アリスは、ボブだけがＢに対応する秘密鍵を知っていると確信すること
はできるが、アリスはボブが実際に秘密鍵を知っていることは確信できない、という事実
によるものである。しかし、間もなく、アリスは、ボブに秘密鍵を用いるように求める。
このように、アリスは彼女がＢを使う必要があるのとほぼ同時に、この問題に気がつくこ
とができる。

半集約署名に関して、もし、署名端末ｊが暗示的証明書Ｃ_{Ｓｉｇｎｅｒｊ}を有するな
らば、検証装置１４は、署名端末ｊの公開鍵をＱ_{Ｓｉｇｎｅｒｊ}＝Ｈａｓｈ（Ｃ_{Ｓｉｇ
ｎｅｒ ｊ}，Ｉ_{Ｓｉｇｎｅｒ ｊ}）＋Ｑ_{ＣＡ ｊ}にしたがって算出する。この式において、
Ｉ_{Ｓｉｇｎｅｒ ｊ}は署名端末ｊに対応する証明書情報であり、Ｑ_ＣＡｊは、暗示的証明
書Ｃ_{Ｓｉｇｎｅｒ ｊ}を発行したＣＡの公開鍵である。

例えば、検証装置１４が、署名端末２がＥＣＰＶＳを用いて署名した平文を復元しよう
とする場合、署名端末１４は、通常、ｈ_２’＝ＨＡＳＨ（ｃ_２｜｜Ｖ）を計算し、整数ｅ
_２’に変換して、そこから、Ｑ_２’＝ｓ_２Ｇ−ｅ_２’Ｗを計算して、最終的にＸ_２＝ＫＤ
Ｆ（Ｑ_２’）を算出する。ここで、暗示的証明書Ｃ_２がある場合は、上記各計算は、代わ
りに、ｈ_２’＝ＨＡＳＨ（ｃ_２｜｜Ｖ）ＨＡＳＨ（ｃ_２｜｜Ｉ_２）ｍｏｄｎ、および、
Ｘ_２＝ｓ_２Ｇ＋ｅ_２’Ｃ_２＋Ｈａｓｈ（ｃ_２｜｜Ｖ）Ｑ_ＣＡ２のようにそれぞれ行われる
。

シャミルのトリック（Shamir’s trick）、および、ソリナス（Solinas）のＪＳＦ（“
Joint SparseForm”）などとして知られる既知の方法は、Ｃ_２からＱ_２をまず算出して
から、上述の式にてＸ_２を算出するのに比べて、Ｘ_２の１つの計算で、計算速度を上げる
ことができる。明示的名証明書が用いられた場合、検証装置１４は、公開鍵Ｑ_２に基づい
て算出されたＣＡの明示的署名を検証する必要があるが、これにはより長い時間かかると
理解される。

よって、半集約ＥＣＰＶＳ署名のいくつかの変形例が用いられることが分かる。上述の
とおり例示された薬剤サプライチェーン２２に関しては、製造業者、卸売業者、流通者、
および、荷送人は、それぞれ、荷物１８に付けられたＲＦＩＤタグ２０に、彼ら自身のＥ
ＣＰＶＳを追加してもよい。ＲＦＩＤタグ２０上のデータに利用できるスペースは限られ
ているため、半集約署名は、１つの限られたスペースの中により多くの署名をはめ込むこ
とを可能にするので、上記のような用途に有益である。荷物１８が薬局に到着すると、集
約署名の検証が可能となる。その結果、薬局は、サプライチェーン２２の全配送工程を通
じて、認証された通信者によって配送処理がなされたものと結論付けることができる。上
記の原則は、同様に、他のシステムにも適用され、製薬環境や、ＲＦＩＤ認証システムに
おける使用に限定されないことは明らかである。

〔完全集約ＥＣＰＶＳ署名（Fully-Aggregate ECPVS Signatures）〕
複数の署名端末の協力が得られるある場面において、完全集約ＥＣＰＶＳ署名方式を用
いることができる。以下の方式においては、Ｔ個の署名端末が協働して、通常Ｔ個の別個
のＥＣＰＶＳ署名となるものを、Ｔ個の全署名端末のＥＣＰＶＳ署名を効果的に１つに集
約する。

一般に、署名端末ｊは、秘密鍵ｗ_ｊと公開鍵Ｗ_ｊとを有する場合、署名端末ｊは、一時
鍵対（ｋ_ｊ，Ｑ_ｊ）を生成し、その後、従来のＥＣＰＶＳでされているように、また、上
で詳細が説明されたように、暗号鍵Ｘ_ｊ＝ＫＤＦ（Ｑ_ｊ）を生成する。集約暗号鍵は、そ
の後、Ｘ＝Ｘ_１＋Ｘ_２＋．．．＋Ｘ_Ｔにしたがって算出される。

上述の各記述のように、この場合、メッセージＭの復元可能な部分Ｈが、暗号鍵を用い
て暗号化される。ここでは、暗号鍵は暗号文ｃ＝ＥＮＣＸ（Ｈ）を取得するための集約暗
号鍵Ｘである。復元可能な部分が変わる場合、ＨはＨ_ｊに置き換えられ、ｃはｃ_ｊに置き
換えられる。

それから、中間要素ｈ＝ＨＡＳＨ（ｃ｜｜Ｖ）がｃから算出され、中間要素ｈは、整数
ｅに変換される。そして、各署名端末ｊは、“ｓ”要素を算出する。例えば、ｓ_ｊ＝ｅｗ
_ｊ＋ｋ_ｊ（ｍｏｄｎ）にしたがって算出する。

集約ｓ値は、その後、Ｓ＝Ｓ_１＋．．．＋Ｓ_Ｔにしたがって算出され、集約署名は（ｃ
，ｓ）となる。ここで、ｃはＨを暗号化する。個々に区別されたメッセージの部分Ｈ_ｊが
ある場合、集約署名は、半集約署名、すなわち、（ｃ_１，．．．，ｃ_Ｔ，ｓ_Ｔ）と一見類
似している。後者の集約署名は、前者の署名ほど完全には集約されていない。これは、完
全集約において、メッセージ拡張は、署名端末の数が増えるにつれて大きくはならないが
、各暗号文ｃ_ｊが冗長性を与えるようにメッセージ拡張にいくらか貢献しているためであ
る。

これを克服するために、ＥＣＰＶＳにおいて利用するための復元可能なメッセージＨ_ｊ
に埋め込みを行う一般的な方法は、十分に長い文字列ＳをメッセージＨ_ｊの先頭に付けて
Ｈ_ｊ’＝Ｓ_ｊ｜｜Ｈ_ｊとするものである。もし全ての署名端末が同一のＳ_ｊを用いて、Ｓ
_ｊ＝Ｓとする場合、署名端末に共通するある固定文字列ｃと、各署名端末の固有の文字列
ｃ_ｊ’とについて、ｃ_ｊ＝ＥＮＣ_Ｘ（Ｈ_ｊ）＝ＥＮＣ_Ｘ（Ｓ｜｜Ｈ_ｊ）＝ｃ｜｜ｃ_ｊ’で
あってもよい。対称暗号方式が、ストリーム暗号の性質を有する場合、上述したとおりに
なる可能性が高い。ＣＢＣモードにおけるＡＥＳなどのような対称暗号方式に関して、Ｓ
が、（一般に１２８ビット、または、１６バイトの）ＡＥＳのブロックサイズと一致する
ある長さを有する場合には、上述したとおりになる。この場合、集約署名は、より簡潔に
、（ｃ，ｃ_１’，．．．，ｃ_Ｔ’，ｓ）と表すことができる。そして、メッセージ拡張は
、（ｃ，ｓ）だけとなる。これは、単一の署名がなされたメッセージのサイズであり、完
全集約となる。

ストリーム暗号が用いられる場合、メッセージのどこに共通部分があっても、暗号文も
共通の部分を有する。したがって、メッセージ拡張をさらに減らすために共通の暗号文の
部分が一度だけ送られる。そのため、共通部分がメッセージの先頭でなくてもどこで起こ
っているのかにかかわらず、暗号文の共通部分を活用できる。これは、例えば、ストリー
ム暗号のようなＣＴＲモード、または、（６４、または、１２８ビットの塊の）ＥＣＢモ
ードにおいて適用されるブロック暗号についてと同様に、ある固定された形式を有するメ
ッセージについて、起こりうる。

検証用に、１つの可視部Ｖがある場合、中間要素は、ｈ’＝ＨＡＳＨ（ｃ｜｜Ｖ）にし
たがって算出され、前述のように、ｈ’は整数ｅ’に変換される。そして、一時公開鍵Ｑ
’は、Ｑ’＝ｓＧ−ｅ’（Ｗ_１＋．．．＋Ｗ_Ｔ）にしたがって算出され、そこから、復号
鍵が、Ｘ＝ＫＤＦ（Ｑ’）として算出される。しかし、個々に区別される明らかな部位Ｖ
_ｉがある場合、各中間要素は、ｈ_ｊ’＝ＨＡＳＨ（ｃ｜｜Ｖ_ｊ）にしたがって算出され、
一時公開鍵Ｑ’は、Ｑ’＝ｓＧ−（ｅ_１’Ｗ_１＋．．．＋ｅ_Ｔ’Ｗ_Ｔ）にしたがって算出
されることに注意されたい。また、復元可能な部分Ｈが、署名端末１６によって異なる場
合、各ｃの存在は、ｃ_ｊに置き換えられることにも注意されたい。

Ｑ’＝ｓＧ−ｅ’（Ｗ_１＋．．．＋Ｗ_Ｔ）の計算は、一般的により効率的に計算できる
だけでなく、（ｃ，ｓ）が公開鍵Ｗ_１＋Ｗ_２＋．．．＋Ｗ_Ｔに対して有効なＥＣＰＶＳ署
名であることを示している。

それから、検証装置１４は、復号鍵Ｘを用いてｃを復号化することにより、平文Ｈ’を
取得してもよい。復号鍵Ｘは、同じＫＤＦを用いることによって一時鍵Ｑ’から導き出せ
るものである。Ｈ’が必要な冗長性を有する場合、メッセージＭを、例えば、Ｈ’とＶと
を連結することによって再構築することができる。そして、検証装置１４は、各署名端末
が上記メッセージに署名したと結論付けることができる。

図２３および図２４を参照にして、署名端末１ないし３までを用いた例を示す。図２３
に示すとおり、各署名端末１６は、Ｘを算出する際、１つの要素を提供する。そして、各
署名端末１６は、中間要素ｈ’を用いて、署名に利用される集約体ｓに与えられる“ｓ”
要素を算出する。

また、図２４に示すとおり、一時公開鍵が、各署名端末の公開鍵の組み合わせを用いて
再構築され、復元可能な部分Ｈの表記Ｈ’は、公開鍵を用いてｃから復号される。

各署名端末１６が、個々に区別された復元可能な部分Ｈ_ｊを用いる場合、Ｈ_ｊ’を復元
するステップは、Ｈ_ｊ’＝ＤＥＣ_Ｘ（ｃ_ｊ）に置き換えられる。

上述の完全集約方法では、各署名端末１６の積極的な関与が必要となる。新しい署名端
末１６が集約体に加えられる場合、先の署名端末らは、新しい寄与（contribution）ｓ_ｊ
を署名要素ｓに提供する必要がある。新しい署名端末が別の署名を加えることができた場
合、半集約ＥＣＰＶＳと比較すると不都合がある。したがって、半集約署名、または、完
全集約署名のどちらが、所定の用途に対してより適切であるのかを決定するのに上述の検
討が用いられる。

安全上の理由のため、Ｑ_{Ｓｉｇｎｅｒ ｊ}についての証明書を取得した署名端末ｊが、
秘密鍵の所持証明（ＰＯＰ；proof-of-possession）を、ＣＡに（または、それができな
い場合は検証装置に）提供することが、集約ＥＣＰＶＳにおいては好ましい。通常、公開
鍵に署名するためのＰＯＰは、ＣＡに送付された証明書の要求に署名することによってな
される。検証装置は、通常、ＣＡが証明書を発行する時に、ＣＡに頼って、各証明書の対
象主体からＰＯＰを取得する。

また、完全な集約ＥＣＰＶＳ署名は、暗示的証明書と合わせても機能する。例えば、署
名端末ｊが、暗示的証明書Ｃ_{Ｓｉｇｎｅｒ ｊ}を有する場合、検証装置１４は、署名端末
ｊの公開鍵を、Ｗ_ｊ＝Ｈａｓｈ（Ｃ_{Ｓｉｇｎｅｒｊ}，Ｉ_{Ｓｉｇｎｅｒ ｊ}）Ｃ_{Ｓｉｇｎｅ
ｒ ｊ}＋Ｑ_{ＣＡ ｊ}にしたがって算出することが可能である。ここで、Ｉ_{Ｓｉｇｎｅｒｊ}
は署名端末ｊに関連付けられた証明書情報であり、Ｑ_ＣＡｊは、暗示的証明書Ｃ_{Ｓｉｇ
ｎｅｒ ｊ}を発行したＣＡの公開鍵である。半集約署名の場合と同様に、Ｑ_ｊの計算が、
Ｘの算出用の式に代用されてもよい。これは、まずＱ_ｊを算出してからＸを算出する場合
よりも、よりよい性能をもたらすことが可能である。

〔その他の署名方式〕
他のエルガマル（ELGamal）タイプの署名は、上述の半集約方式または上記完全集約方
式を適用するために、ＥＣＰＶＳに関する上記の原理を用いることができる。ＥＤＣＳＡ
のような、他の署名方式には、追加の検討を当然必要とする、十分に異なった特徴がある
。

〔ＥＣＤＳＡ署名の集約（Aggregating ECDSA Signatures）〕
例えば、ＥＣＤＳＡがＲＦＩＤタグ２０に署名するために使われる薬剤サプライチェー
ン２２においても、ＥＣＤＳＡ署名をひとまとめにすることが望ましい。図２５および図
２６は、そのような実施形態を示す。

上記と同様に、Ｔ個の署名端末が、どのようにして、対応するＴ個のＥＣＤＳＡ署名が
有効な場合に、および、その場合にのみ有効になる完全集約署名を作成するために、協力
できるかを検討する。上述のＥＣＤＳＡに関する記載が参照にされる。

各署名端末は、ランダムな値ｋ_ｊを選択し、Ｒ_ｊ＝ｋ_ｊＰの値を算出する。この算出結
果は、別の署名端末らに送信される。共通の値のＲは、Ｒ＝Ｒ_１＋．．．＋Ｒ_Ｔにしたが
って算出される。よって、Ｒ＝ｋＰのように対応するｋは、ｋ＝ｋ_１＋．．．＋ｋ_Ｔとな
る。署名端末ｊは、共通鍵ｋに提供したｋ_ｊしか知らないので、個々の署名端末のいずれ
も値ｋを知らない。同様に、ｄ＝ｄ_１＋．．．＋ｄ_Ｔは、各署名端末の共用秘密鍵を表す
。ここでは、個々の署名端末のどれにも、ｄの値全体は分からない。したがって、対応す
る公開鍵は、個々の署名端末の公開鍵の和、すなわち、Ｗ＝ｄＰ＝ｄ_１Ｐ＋．．．＋ｄ_Ｔ
Ｐ＝Ｗ_１＋．．．＋Ｗ_Ｔとして算出される。

第１の署名要素ｒは、ｒ＝ｆ（Ｒ）にしたがって算出される。ここで、ｆ（）は、特定
のＥＣＤＳＡの実施形態において、ある点のｘ座標を整数に変換するために通常用いられ
る関数であり、ｎを法とする整数を減少させる関数である（上記のＥＤＣＳＡの定義も参
照のこと）。

最後に、第２の署名要素ｓが、ｓ＝ｋ^−１（Ｈ（ｍ）＋ｒｄ）ｍｏｄｎにしたがって
算出されて、上記署名が（ｒ，ｓ）のように算出される。この署名は、共通公開鍵Ｗ＝Ｗ
_１＋．．．＋Ｗ_Ｔに基づくメッセージＭ上の有効なＥＣＤＳＡ署名となる。

集約ＥＣＤＳＡ署名の検証は、検証装置１４が、まず、共通公開鍵Ｗ＝Ｗ_１＋．．．＋
Ｗ_Ｔ（ここで、Ｗ_ｊは署名端末ｊの公開鍵である）を算出すること、および、共通公開鍵
Ｗに基づいて（例えば、ＲＦＩＤタグ２０を読み取ることによって）、（ｒ，ｓ）を検証
することによって行われる。

値ｓは、図示されるどの個別の署名端末１６も完全には知ることができない秘密の値で
ある、ｄおよびｋから算出される。同様に、どの署名端末１６も、他のどの署名端末の秘
密鍵も知ることができない。このレベルの安全性を維持するために、各署名端末１６は、
複数の当事者による安全な計算を行うための既知の方法の１つを用いることができる。そ
の方法とは、複数の主体が、どの当事者もそれ自身の秘密を他の当事者に一切明かすこと
なく、個々に秘密を保持する複数の関数である値を計算することを可能にする方法である
。安全な複数当事者の計算の既知の方法は、チャウム（Chaum）他著の“複数当事者の無
条件に安全なプロトコル（Multi-party unconditionally secure protocols）”（in Pro
c. of ACM STOC’88,1988）、および、ベン・オア（Ben-Or）他著の“非暗号の耐障害性
分散型計算の方式ための完全性定理（Completeness theorems for non-cryptographic fa
ult-tolerantdistributed computation）”（in Proc. of ACM STOC’88, 1988, pp. 1-
10）に記載されている。

以上のとおり、複数の署名端末からの複数の署名を、メッセージ拡張をより少なくして
達成できることが明らかになった。半集約署名方式と完全集約署名方式の両方が、利用可
能であり、特に、ＥＣＰＶＳおよびＥＣＤＳＡに適用可能である。複数署名は、上述の署
名のための保存スペースの量が確保しにくい応用場面において特に有益である。そして、
複数署名によって、例えば、製剤サプライチェーン２２におけるＲＦＩＤタグ２０のよう
に、製造工程の様々な段階で署名を書き込むことが可能になる。

当該発明は、具体的な実施形態を参照にして上記に記載されたが、請求項に示した発明
の精神、および、範囲で種々の変更が可能であり、その様々に変更された実施形態も、本
発明の技術的範囲に含まれることは、当業者に明らかである。

Claims (19)

1. 認証されたＲＦＩＤシステムにおける複数のＲＦＩＤリーダの検証鍵を管理するための方法であって、
   前記複数のＲＦＩＤリーダのうちの１つ以上のＲＦＩＤリーダのどれが１つ以上の製品タイプを認証する許可を有するのかを示す一組の許可を決定することと、
   前記複数のリーダのうちの１つ以上のリーダに対して、前記一組の許可に従って、一組の検証鍵を作成することであって、各検証鍵は、特定の製品タイプに関連付けられている、ことと、
   前記複数のＲＦＩＤリーダのそれぞれに前記一組の検証鍵のそれぞれを配布することと
   を含む、方法。
2. 前記配布することは、前記ＲＦＩＤリーダへの専用の接続が必要とならないように、定期的に行われる、請求項１に記載の方法。
3. 前記複数のＲＦＩＤリーダのうちの１つ以上からの鍵更新要求を受信することを含み、
   前記一組の許可を決定することは、新しい各許可を確認することを含む、請求項１に記載の方法。
4. 新しいＲＦＩＤリーダから登録要求を受信することと、
   前記新しいＲＦＩＤリーダのために新しい一組の許可を決定することと
   を含む、請求項１に記載の方法。
5. 新しい検証鍵に関連付けられた証明書要求を受信することと、
   前記新しい検証鍵の証明書を返信することと、
   前記複数のリーダのうちのどのリーダが前記証明書に対する権限があるのかを決定することと、
   前記許可を更新することと、
   後の更新のために前記証明書を格納することと
   を含む、請求項１に記載の方法。
6. 前記検証鍵の使用を示すレポートを受信することと、
   前記使用に収益を関連付けることと
   を含む、請求項１に記載の方法。
7. 対応するＲＦＩＤタグに書き込まれた署名の数を示すレポートを受信することと、
   書き込まれた前記署名の数に収益を関連付けることと
   を含む、請求項１に記載の方法。
8. 予約支払いの受領に従って、前記配布を行うことを含む、請求項１に記載の方法。
9. 認証されたＲＦＩＤシステムにおける複数のＲＦＩＤリーダの検証鍵を管理するためのコンピュータ実行可能な命令を格納するコンピュータ読み取り可能な媒体であって、
   前記認証されたＲＦＩＤシステムにおける複数のＲＦＩＤリーダの検証鍵を管理することは、
   前記複数のＲＦＩＤリーダのうちの１つ以上のＲＦＩＤリーダのどれが１つ以上の製品タイプを認証する許可を有するのかを示す一組の許可を決定することと、
   前記複数のリーダのうちの１つ以上のリーダに対して、前記一組の許可に従って、一組の検証鍵を作成することであって、各検証鍵は、特定の製品タイプに関連付けられている、ことと、
   前記複数のＲＦＩＤリーダのそれぞれに前記一組の検証鍵のそれぞれを配布することと
   によって行われる、コンピュータ読み取り可能な媒体。
10. 複数のＲＦＩＤリーダを有する認証されたＲＦＩＤシステムのための鍵管理システムであって、前記鍵管理システムは、
    前記複数のＲＦＩＤリーダのうちの１つ以上のＲＦＩＤリーダのどれが対応するＲＦＩＤタグを有する１つ以上の製品タイプを読み取る許可を有するのかを示す一組の許可を決定することと、
    前記許可に従って、前記複数のリーダのそれぞれに一組の検証鍵を作成することと、
    前記リーダに前記検証鍵を配布することと
    を行うように構成されている、鍵管理システム。
11. 前記検証鍵の証明書を発行する証明書エージェントと、証明書サーバと、前記検証鍵に関連付けられた証明書を格納するための条件付アクセスデータベースとを含む、請求項１０に記載の鍵管理システム。
12. ＲＦＩＤタグの署名と前記検証鍵を用いたＲＦＩＤタグの検証とを監視する少なくとも１つの制御部を含む、請求項１０に記載の鍵管理システム。
13. 前記ＲＦＩＤリーダへの専用の接続が必要とならないように、前記配布が、予定された間隔で行われる、請求項１０に記載の鍵管理システム。
14. 前記複数のＲＦＩＤリーダのうちの１つ以上からの鍵更新要求を受信するように構成されており、前記一組の許可を決定することは、新しい許可を確認することを含む、請求項１０に記載の鍵管理システム。
15. 新しいＲＦＩＤリーダからの登録要求を受信することと、
    前記新しいＲＦＩＤリーダのために新しい一組の許可を決定することと
    を行うように構成されている、請求項１０に記載の鍵管理システム。
16. 新しい検証鍵に関連付けられた証明書要求を受信することと、
    前記新しい検証鍵の証明書を返信することと、
    前記複数のリーダのうちのどのリーダが前記証明書に対する権限があるのかを決定することと、
    前記許可を更新することと、
    後の更新のために前記証明書を格納することと
    を行うように構成されている、請求項１０に記載の鍵管理システム。
17. 前記検証鍵の使用を示すレポートを受信することと、
    前記使用に収益を関連付けることと
    を行うように構成されている、請求項１０に記載の鍵管理システム。
18. 対応するＲＦＩＤタグに書き込まれた署名の数を示すレポートを受信することと、
    書き込まれた前記署名の数に収益に関連付けることと
    を行うように構成されている、請求項１０に記載の鍵管理システム。
19. 予約支払いの受領に従って、前記配布を実施するように構成されている、請求項１０に記載の鍵管理システム。

Images