ＮＤＥＦメッセージで選択的にレコードを保安するための装置及び方法
ＮＤＥＦメッセージのレコードを選択的に保安するための方法が提供される。前記方法のうちの１つは、前記ＮＤＥＦメッセージに配置マーカ署名レコードを配置する過程を含む。前記配置マーカ署名レコードは、修正された署名ＲＴＤ（signature Record Type Definition）である。ＮＤＥＦメッセージで前記配置マーカ署名レコードの以前のレコードの第１セットは保安されない。また、前記の方法は、配置マーカ署名レコードに後続するレコードの第２セットを保安する過程を含む。他の方法は、署名ＲＴＤに保安されたバイトフィールド（secured bytes field）を配置する過程を含む。保安されたバイトフィールドは、署名ＲＴＤのこのフィールドに先行する保安されるデータのバイト数を表す。また、前記方法は保安されたバイトフィールドの値に基づき、署名ＲＴＤにおけるこのフィールドに先行するレコードのデータを保安する過程を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にＮＦＣ（Near Field Communication）技術に関し、特にＮＦＣ保安(security)ＲＴＤ（Record Type Definition）で保安される（secured）レコードを識別する方法に関する。
【背景技術】
【０００２】
ＮＦＣ技術は、移動端末機のような多様なハンドヘルド装置で使われており、主な使用ケースは、情報共有、支払い、及び発券及び旅行のようなアプリケーションで使用されている。情報は、ＮＦＣ ＲＴＤ（Record Type Definition）に従って所定のＮＦＣタグを使用してＮＦＣを通じて交換できる。
【０００３】
ＮＦＣフォーラムＴＭで、保安ワークグループ（Work Group：ＷＧ）は署名ＲＴＤと呼ばれるレコードタイプを定義し、これはＮＤＥＦ（NFC Data Exchange Format）メッセージのレコードとして含まれることができる。署名ＲＴＤは、ＮＤＥＦメッセージで信頼性及びレコードの一部または全ての無欠性を検証する１つの方式を提供する。署名ＲＴＤはデジタル署名を含み、公認認証書（certificates）のように、予め発行された証明書を使用して検証できる。
【０００４】
アプリケーションの広域はＮＦＣリンクの上でサポートできる。典型的に、ＮＦＣ装置の動作モードは、リーダ／ライタ（Reader/Writer）モード、ピア・トゥ・ピア（Peer To Peer）モード、及びカードエミュレーション（Card Emulation）モードに分類できる。ピア・トゥ・ピアモード通信では、ＮＦＣ装置の両方とも類似な能力を有することができ、前記装置の間には差がない。リーダ／ライタモード通信では、前記装置のうちの１つは、リーダ／ライタの能力を有し、他の装置は単純なタグを格納する。カードエミュレーションモード通信では、装置のうちの１つはリーダであり、残りの他の装置はタグまたはスマートカードまたはクレジットカードの細部事項を格納するＮＦＣ装置となることができる。
【０００５】
ＮＦＣ通信で使われたデータは格納されることができ、幾つかのフォーマットがある。ＮＤＥＦメッセージは、ＲＴＤと呼ばれる特定の定義を有することができる１つ以上の個別的なレコードの集合体である。ＮＦＣフォーラムＴＭでは、幾つかのよく知られたＲＴＤを定義している。ＮＦＣの一部の典型的なアプリケーションは、スマートポスター、構成情報のハンドオーバー、ウェブアクセスなどである。ＲＴＤは、ＮＦＣ標準ボディーにより定義され、推薦書として出刊された。このようなＲＴＤは個別的に使用できるか、ＮＤＥＦメッセージの一部として使用できる。レコードは、例えば、タイプ、ペイロード長さ、及び付加的なＩＤフィールドのようなレコードのための制御情報を羅列した少数のヘッダフィールドを有する。アプリケーションに特定されたデータは、レコードのペイロードフィールドに格納される。ＮＤＥＦメッセージの細部フォーマットは、NFC Data Exchange Format (NDEF) , Technical Specification - NFC ForumTM NDEF 1.0 NFCForum-TS-NDEF_1.0 - 2006-07-24において提供されている。
【０００６】
ＮＦＣの典型的なアプリケーションの一部は、スマートポスター、ｅ−チケットティング、クーポン、ロイヤリティーポイント、ならびにｖカード交換、イメージ転送のようなピア・トゥ・ピアアプリケーション等である。
【０００７】
前述したアプリケーションに対し、前記アプリケーションデータは１つのレコードまたはマルチプルレコードで形式格化（formatted）できる。
【０００８】
ＮＤＥＦメッセージはいくつかの所定のＲＴＤに後続する個別的なレコードの集合体である。ＮＤＥＦレコードのデータは、無欠性保護及びＮＦＣ署名ＲＴＤレコードを追加することによって、レコードの生成器（creator）を認証するために保安される。署名ＲＴＤ生成器は、無欠性保護を提供するデジタル署名フィールドを生成するために、よく知られたアルゴリズムを使用する。メッセージのためのデジタル署名の生成に使われるキーは、署名ＲＴＤにまた羅列される公認認証書で提供される。
【０００９】
本明細書で参照される、署名ＲＴＤの仕様を説明したＮＦＣフォーラムＴＭ文書は、NFC Forum-TS-RTD_Signature_0.99 - Technical Specification NFC ForumTM RTD-Signature 0.99 - NFC Forum-TS-RTD_Signature_0.99 - 2008-06-10, DRAFTである。
【００１０】
１つ以上の署名ＲＴＤレコードを、前記ＮＤＥＦメッセージに１つ以上のレコードのための無欠性及び認証のような保安機能を提供するように、ＮＤＥＦメッセージに追加してもよい。署名ＲＴＤ仕様においては、署名ＲＴＤの署名フィールド（signature field）により提供される保安のためのレコードを正確に識別する必要がある。バージョン０．９９の以前の署名ＲＴＤ仕様は、与えられた署名ＲＴＤレコードがこの署名ＲＴＤレコードの以前の全てのレコードに対する保安を提供するか、同一ＮＤＥＦメッセージでの以前の署名ＲＴＤ及び現在の署名ＲＴＤレコードの間にあるレコードが保護できることを定義している。
【００１１】
しかしながら、署名ＲＴＤレコードにより保安される前記レコードを特定する上記参照された定義は、保安される必要のないＮＤＥＦメッセージの開始において一部のレコードを除外することが不可能であるので、柔軟でない。つまり、署名ＲＴＤにより保安されるＮＤＥＦメッセージにおけるレコードのブロックを識別する方法がない。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、署名ＲＴＤレコードにおいて保安されるレコードまたはバイトのシーケンスをＮＤＥＦレコードにおいて識別するための方法を提供することにある。
【課題を解決するための手段】
【００１３】
本発明は、ＮＤＥＦ（NFC Data Exchange Format）メッセージで選択的にレコードを保安するための方法であって、前記ＮＤＥＦメッセージで配置マーカ署名レコードを配置する過程と、有効署名を含む署名（signature）ＲＴＤを使用して前記配置マーカ署名レコードに後続するレコードの２番目のセットを保安する過程と、を含み、前記配置マーカ署名レコードは、修正された署名ＲＴＤ（Record Type Definition）であり、前記配置マーカ署名レコードに先たつレコードの一番目のセットは保安されないことを特徴とする、ＮＤＥＦメッセージで選択的にレコードを保安するための方法を提供する。
【００１４】
また、本発明は、ＮＤＥＦ（NFC Data Exchange Format）メッセージで選択的にレコードを保安するための方法であって、署名ＲＴＤ（Record Type Definition）でsecure_bytesフィールドを設定する過程と、前記secure_bytesフィールドの値に基づいて前記署名ＲＴＤで前記secure_bytesフィールドに先たつ前記ＮＤＥＦメッセージにデータを保安する過程を含み、前記secure_bytesフィールドは前記署名ＲＴＤで署名により保安されたデータバイトの数を表すものであることを特徴とする、ＮＤＥＦメッセージで選択的にレコードを保安するための方法を提供する。
【発明の効果】
【００１５】
本発明によれば、署名ＲＴＤレコードで保安されたレコードまたはバイトのシーケンスを識別することが可能であるという利点が得られる。
【図面の簡単な説明】
【００１６】
【図１】一対のＮＦＣ装置の間の通信を示す図である。
【図２】ＮＦＣ技術をサポートすることに要求される典型的なプロトコルスタックを示す図である。
【図３】ＮＤＥＦ構造を表現した図である。
【図４】署名ＲＴＤレコードのペイロードを示す図である。
【図５】署名ＲＴＤの署名フィールドでのフィールドを示す図である。
【図６】本発明の実施形態に従って、署名ＲＴＤレコードの修正された構造を示す図である。
【図７】本発明の実施形態に従って、署名ＲＴＤレコードの修正された構造を示す図である。
【図８】本発明の実施形態に従って、ＮＤＥＦで保安されたレコードを選択するための第１方法を示す図である。
【図９】本発明の実施形態に従って、署名ＲＴＤのための代案的な構造を示す図である。
【図１０】本発明の実施形態に従って、ＮＤＥＦで保安されるレコードの第２方法を示す図である。
【図１１】本発明の実施形態に従って、署名フィールドのサブフィールドを示す図図である。
【図１２】本発明の実施形態に従って、ＮＤＥＦで選択的にレコードを保安するための方法を示すフローチャートである。
【図１３】本発明の他の実施形態に従って、ＮＤＥＦで選択的にレコードを保安するための方法を示すフローチャートである。
【図１４】本発明の実施形態に従うＮＦＣ装置の内部構成を示すブロック構成図である。
【発明を実施するための形態】
【００１７】
この分野に属した当業者は図面に記載された各構成要素は明確に、かつ簡潔に描写されたが、これに限定されるのではない。例えば、図面に記載された構成要素のそれぞれの範囲は他の構成要素と関連して強調できるので、本発明の多様な実施形態の理解増進を助ける。
【００１８】
添付の図面において、類似なレファレンス番号は、同一であるとか、または機能的に類似な構成要素に関連できる。このようなレファレンス番号は多様な実施形態を明確にするために詳細な説明で使われ、本発明の多様な例及び長所を説明することに使われる。方法ステップ及びシステム構成部は図面で有用なシンボルにより表現され、単に本発明の理解のために関連した特定の細部事項を表すことが分かる。また、この分野に属した当業者に容易に明白になる細部事項は開示しない。本文書で第１及び第２のような関連用語は、実際の関係や、エンティティ間の順序を暗示する必要なく、他のエンティティからあるエンティティを区別するために使用される。
【００１９】
本発明はＮＤＥＦ（NFC Data Exchange Format）で保安されたレコードを識別するための方法を提案する。本発明の第１実施形態において、署名ＲＴＤにより保安されるレコードのセットの開始は、開始／配置マーカ（Begin/Place Marker）署名レコードを使用して指示される。本発明の第２実施形態において、保安されたバイト（secured bytes）と呼ばれる新たなフィールドが署名ＲＴＤレコードに追加される。保安されたバイトフィールドは、署名ＲＴＤにより保護されるデータのバイトを識別するために使用することができる。このアプリケーションは、保安されたバイトフィールドを使用することにより、１つの署名ＲＴＤを使用してマルチプルレコード及びマルチプルＮＤＥＦメッセージからデータを保護する能力を有する。
【００２０】
図１は、一対のＮＦＣ装置の間の通信を図示している。前記装置は３個の互いに異なるアプリケーションモード（すなわち、ピア・トゥ・ピア（Peer-to-Peer）モード、リーダ／ライタ（Reader/Writer）モード、及びカードエミュレーションモード（Card Emulation）モード）で通信する。ピア・トゥ・ピアモードでは、ＮＦＣ装置の両方とも同様な能力を有することができ、前記装置の間の区別がない。リーダ／ライタモードにおいて、前記装置のうちの１つはリーダ／ライタの能力を有し、他の装置は単純なタグである。カードエミュレーションモードでは、装置のうちの１つはリーダであり、残りの他の装置は単純なタグまたはＮＦＣ装置となることができ、前記ＮＦＣ装置は保安メモリに格納されたレコード形態でクレジットカードの細部事項を格納する。
【００２１】
図２は、ＮＦＣ技術をサポートすることに要求される典型的なプロトコルスタックを図示している。アプリケーションデータは、ＮＤＥＦメッセージ形態でコード化されることができ、ＮＦＣリンクの上で転送できる。ＮＤＥＦフォーマットは、リーダ／ライタ動作モードだけでなく、ピア・トゥ・ピアモードでも使用できる。
【００２２】
図３は、ＮＤＥＦ構造を表現している。一番目のバイトは、多様なビットフィールドでＮＤＥＦメッセージのための制御情報を有する。ビットフィールドは、ＭＢ（Message Begin）フィールド、ＭＥ（Message End）フィールド、ＣＦ（Chunk Flag）フィールド、ＳＲ（Short Record）フィールド、ＩＬ（ID Length）フィールド、及びＴＮＦ（Type Name Format）フィールドである。タイプ、ＩＤ及びペイロードのための多様な長さ及び値が格納される。
【００２３】
図４は、NFC Forum-TS-RTD_Sisgnature_0.99に記述されたように、存在する署名ＲＴＤレコードの従来のペイロードを示している。図４を参照すると、バージョン（Version）フィールド４００は、仕様標準のメジャー（major）またはマイナーバージョンナンバー（minor version number）が記載されている。署名フィールド４０５は、保護されたＮＤＥＦデータのための署名を表すＴＬＶ構造を含んでいる。認証チェーン（Certificate Chain）フィールド４１０は、ＮＤＥＦメッセージの送信器の認証に使用される公認認証書のリストを提供する。
【００２４】
図５は、図４に示す署名ＲＴＤの署名フィールド（Signature Field）４０５のサブフィールドを示す。特に、署名フィールド４０５は、URI（Uniform Resource Identifier）_presentビットフィールド４１５、署名タイプフィールド４２０、署名長さフィールド４２５、及び署名／ＵＲＩフィールド４３０を含む。URI_presentビットフィールド４１５は、署名がレコード自体に含まれているか、または署名／ＵＲＩフィールド４３０により指示されたＵＲＩ（Uniform Resource Identifier）にあるかを表すことに使われる。
【００２５】
図６及び７は、本発明の実施形態に従って、修正された署名ＲＴＤレコードを示す。
【００２６】
図６を参照すると、修正された署名ＲＴＤレコードの一番目のバイトは図７のように３個のサブフィールド５１５、５２０、５２５を有する制御フィールド５００である。
【００２７】
図７を参照すると、制御フィールド５００、すなわちフラグ（Flag）フィールド５１５の一番目の２ビットは、前記署名ＲＴＤレコードが無欠性のためのレコードブロックの開始を表すことに使われるものであるか、認証保護が与えられたか、または前記レコードが署名フィールド５０５を有しているかを表すことに使われる。次に、２つのフィールド５２０、５２５は、各々３ビットフィールドとしてメジャーまたはマイナーバージョンを表記する。前記制御フィールド５００の一番目の２ビットは次のような値のうちの１つを取ることができる。
【００２８】
‘００’は、署名が今後に追加されるように、レコードブロックの初めを表す。これが配置マーカ署名レコードである。
【００２９】
‘１１’は、署名を有する署名レコードであり、‘０１’、‘１０’は今後の使用のための予備である。
【００３０】
図８は、本発明の実施形態に従って、ＮＤＥＦにおいて保全されるレコードを選択する第１方法を示す図である。図８を参照すると、開始／配置ホルダ署名ＲＴＤという名前のレコードはコード化されており、この署名ＲＴＤに後続するレコードが次の署名ＲＴＤまで保安されることをＮＤＥＦパーサに知らせている。したがって、レコードＲ３、Ｒ４、及びＲ５は、レコードＲ２に後続する署名ＲＴＤにより保護される。
【００３１】
図９は、本発明の実施形態に従って、署名ＲＴＤのための代案的な構造を示す。図９は、署名ＲＴＤにより保安されたデータが、情報のバイトを使用して示されている、署名ＲＴＤのための代案的な構造を表現している。
【００３２】
図９を参照すると、保安されたバイトフィールド８０５は、この署名ＲＴＤにおける署名により保安された署名ＲＴＤの該フィールドに先行するデータバイトの数を表している。
【００３３】
図１０は、本発明の実施形態に従って、ＮＤＥＦにおけるレコードを保安する第２方法を示す図である。図１０を参照すると、保安されたバイトフィールドは、署名ＲＴＤフィールドのレコードＲ４及びＲ５のサイズと同一な値に設定される。
【００３４】
図１１は、本発明の実施形態に従って、署名フィールドのサブフィールドを表現したものである。より詳しくは、図１１で開始または配置マーカレコードは、０に設定されたURI_presentまたは署名タイプフィールドを有する。前記タイプフィールドは、デジタル署名を生成するために使用される署名アルゴリズムに関する情報を与えるために使用可能な有効な値が列挙されているテーブルにおいて定められたインデックス値をとることができる。例えば、署名タイプ0x00は、配置マーカレコードを示すために使用されてもよい。
【００３５】
図１２は、本発明の一実施形態に従って、ＮＤＥＦで選択的にレコードを保安するための方法を示すフローチャートである。より詳しくは、図１２は、ＮＤＥＦで選択的にレコードを保安するための方法１１００を示す。
【００３６】
図１２を参照すると、ステップ１１０２で、前記方法１１００が開始される。ステップ１１０４で、配置マーカ署名レコードが定義される。配置マーカ署名レコードは、URI_presentフィールドを‘０’に設定し、署名長さフィールドを‘０’に設定することによって定義できる。‘０’に設定されたURI_presentフィールド及び‘０’に設定された署名長さフィールドの組み合わせが、配置マーカ署名レコードである。また、配置マーカ署名レコードは、署名ＲＴＤのバージョンフィールドをフラグ、メジャーナンバーバージョン、及びマイナーナンバーバージョンに分けることによって定義できる。前記フラグフィールドは、前記レコードが配置マーカ署名レコードまたは署名ＲＴＤであるかを表すことに使われる。追加に、配置マーカ署名レコードは、URI_presentフィールドを‘０’に設定し、署名タイプフィールドを所定の値に設定することによって定義してもよい。‘０’に設定されたURI_presentフィールド及び‘０’に設定された署名タイプフィールドの組み合わせが、配置マーカ署名レコードである。
【００３７】
ステップ１１０６で、配置マーカ署名レコードがＮＤＥＦメッセージに配置される。配置マーカ署名レコードは修正されたＲＴＤである。ＮＤＥＦの配置マーカ署名レコードに先行するレコードの第１セットは保安されない。本発明の実施形態では、前記ＮＤＥＦメッセージの開始までの配置マーカ署名レコードに先行するレコードの第１セットは保安されない。本発明の他の実施形態では、配置マーカ署名レコードに先行する署名ＲＴＤまでの、配置マーカ署名レコードに先行するレコードの第１セットが保安されない。
【００３８】
ステップ１１０８で、配置マーカ署名レコードに後続するレコードの第２セットは保安される。方法１１００は、同一のＮＤＥＦに一部のレコードを保安されていないままで維持する間、一部のレコードを保安するための柔軟性を提供する。その後、前記方法１１００は、ステップ１１１０で終了する。
【００３９】
前述した方法は、署名ＲＴＤの署名を変更することなく、ＮＤＥＦメッセージの保安されていないレコードを削除できる柔軟性を提供する。追加に、ＮＤＥＦメッセージの保安されていないレコードは署名ＲＴＤの署名を変更することなく修正できる。その上、ＮＤＥＦメッセージの保安されていないレコードは署名ＲＴＤの署名を変更することなく追加できる。前記の方法１１００は、下記の方法１を参照して細部的に説明する。
【００４０】
方法１：
【００４１】
署名ＲＴＤにより保安されたレコードのセットの開始を表記するために、開始／配置マーカ署名レコードが保安される一番目のレコードの前に追加される。３個の互いに異なるフィールド表現は、開始／配置マーカ署名レコードを定義することに使用できる。
【００４２】
（ｉ）制御フィールドを使用して開始／配置マーカ署名レコードを定義
【００４３】
署名ＲＴＤレコードは、２つのビットフラグフィールドを含むように修正される。該２ビットフィールドは現在の署名ＲＴＤレコードの一番目のバイトでコード化できる。該２ビットフラグフィールドにより取れる値は、次の通りである。
【００４４】
‘００’は、署名が今後に追加されるようにレコードブロックの開始を表す。これが配置マーカ署名レコードである。
【００４５】
‘１１’は、署名を有する署名レコードであり、‘０１’、‘１０’は今後の使用のために予約されている。
【００４６】
図６、図７、及び図８は、方法１で使用しうる構造の例を提供している。
【００４７】
署名ＲＴＤにより保安されたレコードのセットの開始を表記するために、開始／配置マーカ署名レコードは、００に設定された署名ＲＴＤの制御フィールド５００により保安された第１レコードの前に追加される。署名フィールド５０５は、単に配置マーカレコードであるので、該レコードでは省略してもよい。認証チェーンフィールド５１０は、付加的に該配置マーカレコード自体で規定しても良い。前記配置マーカレコードに認証チェーンフィールド５１０を置くことによって、受信機のＮＤＥＦパーサにある保安エンジンは、署名が算出される以前にメッセージを認証することができる。他の利点は、署名の生成はＮＤＥＦメッセージが読取される時に起こりうるということである。これは、追加された性能の向上を与えることができる。
【００４８】
‘１１’に設定されたフラグビットを有する署名ＲＴＤは、保安されるレコードのセットの以後に配置される。署名ＲＴＤは、無欠性保護のために受信機で検証されるであろう署名を有する。仮に、公認認証書の値が配置マーカ署名レコードで特定されていないならば、署名フィールドセットを有する後の署名ＲＴＤにおいて提供される。
【００４９】
（ii）署名フィールドの一番目のバイトを使用して開始／配置マーカ署名レコードを定義
【００５０】
開始／配置マーカ署名レコードを表現するための他の代案は、署名ＲＴＤの署名フィールド（Signature field）のサブフィールド４１５、４２０、４２５、４３０を使用することである。バージョンフィールド４００は、単にバージョンを表す用途に使われる。署名フィールド（Signature field）のサブフィールド４１５、４２０、４２５、４３０は、図５に図示されている。例えば、２つの署名サブフィールドの組み合わせを配置マーカレコードを表現するために使用してもよい。
【００５１】
１．署名フィールドの一番目のバイトは０に設定できる。これは一番目のビット、URI_presentフィールド４１５は０に設定され、署名タイプフィールド４２０は、例えば０といった所定の値に設定されることを意味する。これは、この署名レコードは有効な署名を有しないが、署名されなければならないか、保安されていないままで残しておかなければならないレコードを識別する専ら配置マーカとして使われる。このようなフォーマットにおいて、署名長さフィールド４２５、署名／ＵＲＩフィールド４３０が署名タイプフィールド４２０に後続する。図１１では、署名長さフィールド４２５及び署名／ＵＲＩフィールド４３０は署名ＲＴＤに存在していない。
【００５２】
２．一番目のビット、URI_Presentフィールド４１５は０に設定され、署名長さフィールド４２５は０に設定される（図５参照）。署名タイプフィールド４２０は、署名の生成に使われるデジタル署名アルゴリズムタイプを表す。認証チェーンフィールド４１０は付加的にあってもよい。配置マーカレコードの署名タイプ及び認証情報を提供することによって受信機におけるＮＤＥＦパーサの保安エンジンは、署名が算出される以前にメッセージを認証することができる。他の利点は、検証目的のために、署名生成はＮＤＥＦメッセージが読取された時に起こることができるということである。これは、追加的な性能向上を与えることができる。
【００５３】
署名タイプが、デジタル署名と一緒に使われた署名アルゴリズムを示すように設定された署名ＲＴＤは、保安されるレコードのセットの以後に配置される。この署名ＲＴＤは、無欠性保護のために受信機で検証されるべきレコードのセットのデジタル署名を有する。仮に、証明値が配置マーカ署名レコードで特定されていなければ、設定された署名フィールドを有する後の署名ＲＴＤに含まれている。
【００５４】
前記の２つの方法のうちの１つを使用することによって、配置マーカ／開始署名ＲＴＤレコードを表現することが可能である。配置マーカ署名ＲＴＤレコードのペイロードは、数バイトロング（bytes long）のみであり、したがって、それらはＮＤＥＦ仕様において定義されているように、ショートレコードとして設定できる（例えば、ＮＤＥＦヘッダのＳＲ＝１に設定、図３参照）。
【００５５】
開始／配置マーカ署名レコードの以前のレコードは、ＮＤＥＦメッセージの開始または他の署名ＲＴＤレコードに至るまで保安されない。これは、一部の大きいレコードまたは共用情報を含むレコードがデジタル署名を使用して保安されないことによってアプリケーションに与えられる追加的な利点である。例えば、図８で、レコードＲ１及びＲ２は、デジタル署名により保護されておらず、レコードＲ３、Ｒ４、及びＲ５は署名により保護されている。
【００５６】
図１３は、本発明の他の実施形態に従って、ＮＤＥＦのレコードを選択的に保安するための方法を示す流れ図である。図１３には、ＮＤＥＦのレコードを選択的に保安するための方法が示されている。
【００５７】
図１３を参照すると、ステップ１２０２で、前記方法１２００は開始される。ステップ１２０４で、secured_bytesフィールドは定義され、この署名ＲＴＤにより保安されたデータの識別に使われる。ステップ１２０６で、secured_bytesフィールドは、署名ＲＴＤにより保安された情報のバイト数に設定され、署名ＲＴＤに、データを保安するデジタル署名が追加される。認証を提供する認証チェーンは、署名ＲＴＤにまた追加される。secured_bytesフィールドは、前記署名ＲＴＤに先行する保安されるバイトの数を表す。ステップ１２０８で、署名ＲＴＤの保安されたバイトフィールドに先行するデータが、保安されたバイトフィールドの値に基づいて保安される。その後、前記方法１２００はステップ１２１０で終了する。前記方法１２００は、方法２を参照して下記で細部的に説明する。
【００５８】
方法２：
【００５９】
図９及び１０を参照すると、新たなフィールド、すなわち保安されたバイトフィールド８０５は、署名ＲＴＤレコードに付加される。このフォーマットにおけるバージョンフィールド８００は、使われた仕様のメジャー及びマイナーバージョンナンバーをだけを有することができる。保安されたバイトフィールド８０５は、該署名ＲＴＤにより保安された該フィールドの以前のデータバイトの数を表す整数値である。これは、現在のＮＤＥＦメッセージのデータだけを表してもよい。代案的に、保安されたバイトは、また現在のＮＤＥＦメッセージの外部にあるＮＤＥＦレコードのデータを含んでもよい。これは、この方法を使用することによる追加的な利点である。ＮＤＥＦパーサは、保安されたバイトフィールド８０５を読取って、署名レコードのこのフィールドに先行するデータの多くのバイトに署名アルゴリズムを適用する。また、署名ＲＴＤレコードのヘッダフィールドは、保安されたバイトに含まれる。
【００６０】
例えば、本発明の一実施形態に従うＮＤＥＦメッセージは、スマートポスターを表現することに使われる。スマートポスターは、典型的にテキストタイプの幾つかのレコード、オーディオ、ビデオデータ、ＵＲＩなどを含むＭＩＭＥタイプを有することができる。図８に示されているＮＤＥＦメッセージは、オーディオデータを有するレコードであるレコードＲ１と、イメージデータを有するレコードであるレコードＲ２と、を有するスマートポスターレコードであってもよい。このスマートポスターの生成器は、２，３の理由によりレコードＲ１及びＲ２をサインしないように選択できる。第１に、これらのオーディオ及びイメージレコードは、大きいレコードとなりうるので、署名の算出に時間がかかる。第２に、仮にこれらがサインされていなければ、それらの上にインストールされた公認認証書を有しない単純な装置でも、レコードＲ１、Ｒ２の情報を得ることができる。レコードＲ３、Ｒ４、及びＲ５は、ＵＲＩタイプ、認証される必要があるエンティティにより提供される価格情報が与えられるテキストとなることができる。したがって、上述の方法１を使用すると、このブロックの開始が、レコードＲ３の以前であってレコードＲ５であるレコードブロックの終端の以後に配置される開始／配置マーカ署名ＲＴＤレコードによりマークされ、署名フィールドと一緒に署名ＲＴＤが配置される。ＮＤＥＦパーサは適切にこのスマートポスターで情報を使用することができ、ここで、レコードＲ１及びＲ２は保安されず、署名生成の間使われない。レコードＲ３、Ｒ４、及びＲ５の内容はレコードＲ５に後続する署名ＲＴＤにある署名フィールドを使用して保安される。
【００６１】
図１４は、本発明の他の実施形態に従うＮＦＣ装置の内部構成を示すブロック構成図である。
【００６２】
図１４で、ＮＦＣメッセージ生成部１３００はＮＤＥＦフォーマットでＮＤＥＦメッセージを生成し、送信部１３１０は生成されたＮＤＥＦメッセージを送信する。
【００６３】
図１２を参照すると、ＮＦＣメッセージ生成部１３００は、ＮＤＥＦメッセージに配置マーカ署名レコードを配置する。配置マーカ署名レコードは修正された署名ＲＴＤであり、ＮＤＥＦに配置されている配置マーカ署名レコードの以前のレコードの第１セットは保安されない。その後、ＮＦＣメッセージ生成部１３００は、有効な署名を含む署名ＲＴＤを使用して配置マーカ署名レコードに後続するレコードの第２セットを保安する。送信部１３１０は、本発明の実施形態に従って生成されたＮＤＥＦメッセージを転送する。
【００６４】
図１３を参照すると、ＮＦＣメッセージ生成部１３００は、署名ＲＴＤのsecure_bytesフィールドを設定する。その後、ＮＦＣメッセージ生成部１３００は、secure_bytesフィールド値に基づいて、署名ＲＴＤのsecure_bytesフィールドの以前のＮＤＥＦメッセージのデータを保安する。secure_bytesフィールドは、前記署名ＲＴＤの署名により保安されているデータのバイト数を表している。送信部１３１０は、本発明の他の実施形態に従って、生成されたＮＤＥＦメッセージを転送する。
【００６５】
本発明の一実施形態が例示及び説明されたが、これは本発明を明確にするためのものであり、その利点はこの実施形態に限定されるのではない。多様な修正、変形、多様性、代替、及び同等のものが請求項に記載されたように本発明の精神及び範囲から逸脱することなく、この分野に属する当業者に明白になる。したがって、詳細な説明及び図面は制限的な機能よりは本発明の例示的な説明としてみなされる。
【符号の説明】
【００６６】
４００ バージョンフィールド
４０５ 署名フィールド
４１０ 認証チェーンフィールド
４１５ URI（Uniform Resource Identifier）_presentビットフィールド
４２０ 署名タイプフィールド
４２５ 署名長さフィールド
４３０ 署名／ＵＲＩフィールド
５００ 制御フィールド
５０５ 署名フィールド
５１５、５２０、５２５ サブフィールド
５１５ フラグフィールド
８０５ バイトフィールド
【技術分野】
【０００１】
本発明は、一般的にＮＦＣ（Near Field Communication）技術に関し、特にＮＦＣ保安(security)ＲＴＤ（Record Type Definition）で保安される（secured）レコードを識別する方法に関する。
【背景技術】
【０００２】
ＮＦＣ技術は、移動端末機のような多様なハンドヘルド装置で使われており、主な使用ケースは、情報共有、支払い、及び発券及び旅行のようなアプリケーションで使用されている。情報は、ＮＦＣ ＲＴＤ（Record Type Definition）に従って所定のＮＦＣタグを使用してＮＦＣを通じて交換できる。
【０００３】
ＮＦＣフォーラムＴＭで、保安ワークグループ（Work Group：ＷＧ）は署名ＲＴＤと呼ばれるレコードタイプを定義し、これはＮＤＥＦ（NFC Data Exchange Format）メッセージのレコードとして含まれることができる。署名ＲＴＤは、ＮＤＥＦメッセージで信頼性及びレコードの一部または全ての無欠性を検証する１つの方式を提供する。署名ＲＴＤはデジタル署名を含み、公認認証書（certificates）のように、予め発行された証明書を使用して検証できる。
【０００４】
アプリケーションの広域はＮＦＣリンクの上でサポートできる。典型的に、ＮＦＣ装置の動作モードは、リーダ／ライタ（Reader/Writer）モード、ピア・トゥ・ピア（Peer To Peer）モード、及びカードエミュレーション（Card Emulation）モードに分類できる。ピア・トゥ・ピアモード通信では、ＮＦＣ装置の両方とも類似な能力を有することができ、前記装置の間には差がない。リーダ／ライタモード通信では、前記装置のうちの１つは、リーダ／ライタの能力を有し、他の装置は単純なタグを格納する。カードエミュレーションモード通信では、装置のうちの１つはリーダであり、残りの他の装置はタグまたはスマートカードまたはクレジットカードの細部事項を格納するＮＦＣ装置となることができる。
【０００５】
ＮＦＣ通信で使われたデータは格納されることができ、幾つかのフォーマットがある。ＮＤＥＦメッセージは、ＲＴＤと呼ばれる特定の定義を有することができる１つ以上の個別的なレコードの集合体である。ＮＦＣフォーラムＴＭでは、幾つかのよく知られたＲＴＤを定義している。ＮＦＣの一部の典型的なアプリケーションは、スマートポスター、構成情報のハンドオーバー、ウェブアクセスなどである。ＲＴＤは、ＮＦＣ標準ボディーにより定義され、推薦書として出刊された。このようなＲＴＤは個別的に使用できるか、ＮＤＥＦメッセージの一部として使用できる。レコードは、例えば、タイプ、ペイロード長さ、及び付加的なＩＤフィールドのようなレコードのための制御情報を羅列した少数のヘッダフィールドを有する。アプリケーションに特定されたデータは、レコードのペイロードフィールドに格納される。ＮＤＥＦメッセージの細部フォーマットは、NFC Data Exchange Format (NDEF) , Technical Specification - NFC ForumTM NDEF 1.0 NFCForum-TS-NDEF_1.0 - 2006-07-24において提供されている。
【０００６】
ＮＦＣの典型的なアプリケーションの一部は、スマートポスター、ｅ−チケットティング、クーポン、ロイヤリティーポイント、ならびにｖカード交換、イメージ転送のようなピア・トゥ・ピアアプリケーション等である。
【０００７】
前述したアプリケーションに対し、前記アプリケーションデータは１つのレコードまたはマルチプルレコードで形式格化（formatted）できる。
【０００８】
ＮＤＥＦメッセージはいくつかの所定のＲＴＤに後続する個別的なレコードの集合体である。ＮＤＥＦレコードのデータは、無欠性保護及びＮＦＣ署名ＲＴＤレコードを追加することによって、レコードの生成器（creator）を認証するために保安される。署名ＲＴＤ生成器は、無欠性保護を提供するデジタル署名フィールドを生成するために、よく知られたアルゴリズムを使用する。メッセージのためのデジタル署名の生成に使われるキーは、署名ＲＴＤにまた羅列される公認認証書で提供される。
【０００９】
本明細書で参照される、署名ＲＴＤの仕様を説明したＮＦＣフォーラムＴＭ文書は、NFC Forum-TS-RTD_Signature_0.99 - Technical Specification NFC ForumTM RTD-Signature 0.99 - NFC Forum-TS-RTD_Signature_0.99 - 2008-06-10, DRAFTである。
【００１０】
１つ以上の署名ＲＴＤレコードを、前記ＮＤＥＦメッセージに１つ以上のレコードのための無欠性及び認証のような保安機能を提供するように、ＮＤＥＦメッセージに追加してもよい。署名ＲＴＤ仕様においては、署名ＲＴＤの署名フィールド（signature field）により提供される保安のためのレコードを正確に識別する必要がある。バージョン０．９９の以前の署名ＲＴＤ仕様は、与えられた署名ＲＴＤレコードがこの署名ＲＴＤレコードの以前の全てのレコードに対する保安を提供するか、同一ＮＤＥＦメッセージでの以前の署名ＲＴＤ及び現在の署名ＲＴＤレコードの間にあるレコードが保護できることを定義している。
【００１１】
しかしながら、署名ＲＴＤレコードにより保安される前記レコードを特定する上記参照された定義は、保安される必要のないＮＤＥＦメッセージの開始において一部のレコードを除外することが不可能であるので、柔軟でない。つまり、署名ＲＴＤにより保安されるＮＤＥＦメッセージにおけるレコードのブロックを識別する方法がない。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、署名ＲＴＤレコードにおいて保安されるレコードまたはバイトのシーケンスをＮＤＥＦレコードにおいて識別するための方法を提供することにある。
【課題を解決するための手段】
【００１３】
本発明は、ＮＤＥＦ（NFC Data Exchange Format）メッセージで選択的にレコードを保安するための方法であって、前記ＮＤＥＦメッセージで配置マーカ署名レコードを配置する過程と、有効署名を含む署名（signature）ＲＴＤを使用して前記配置マーカ署名レコードに後続するレコードの２番目のセットを保安する過程と、を含み、前記配置マーカ署名レコードは、修正された署名ＲＴＤ（Record Type Definition）であり、前記配置マーカ署名レコードに先たつレコードの一番目のセットは保安されないことを特徴とする、ＮＤＥＦメッセージで選択的にレコードを保安するための方法を提供する。
【００１４】
また、本発明は、ＮＤＥＦ（NFC Data Exchange Format）メッセージで選択的にレコードを保安するための方法であって、署名ＲＴＤ（Record Type Definition）でsecure_bytesフィールドを設定する過程と、前記secure_bytesフィールドの値に基づいて前記署名ＲＴＤで前記secure_bytesフィールドに先たつ前記ＮＤＥＦメッセージにデータを保安する過程を含み、前記secure_bytesフィールドは前記署名ＲＴＤで署名により保安されたデータバイトの数を表すものであることを特徴とする、ＮＤＥＦメッセージで選択的にレコードを保安するための方法を提供する。
【発明の効果】
【００１５】
本発明によれば、署名ＲＴＤレコードで保安されたレコードまたはバイトのシーケンスを識別することが可能であるという利点が得られる。
【図面の簡単な説明】
【００１６】
【図１】一対のＮＦＣ装置の間の通信を示す図である。
【図２】ＮＦＣ技術をサポートすることに要求される典型的なプロトコルスタックを示す図である。
【図３】ＮＤＥＦ構造を表現した図である。
【図４】署名ＲＴＤレコードのペイロードを示す図である。
【図５】署名ＲＴＤの署名フィールドでのフィールドを示す図である。
【図６】本発明の実施形態に従って、署名ＲＴＤレコードの修正された構造を示す図である。
【図７】本発明の実施形態に従って、署名ＲＴＤレコードの修正された構造を示す図である。
【図８】本発明の実施形態に従って、ＮＤＥＦで保安されたレコードを選択するための第１方法を示す図である。
【図９】本発明の実施形態に従って、署名ＲＴＤのための代案的な構造を示す図である。
【図１０】本発明の実施形態に従って、ＮＤＥＦで保安されるレコードの第２方法を示す図である。
【図１１】本発明の実施形態に従って、署名フィールドのサブフィールドを示す図図である。
【図１２】本発明の実施形態に従って、ＮＤＥＦで選択的にレコードを保安するための方法を示すフローチャートである。
【図１３】本発明の他の実施形態に従って、ＮＤＥＦで選択的にレコードを保安するための方法を示すフローチャートである。
【図１４】本発明の実施形態に従うＮＦＣ装置の内部構成を示すブロック構成図である。
【発明を実施するための形態】
【００１７】
この分野に属した当業者は図面に記載された各構成要素は明確に、かつ簡潔に描写されたが、これに限定されるのではない。例えば、図面に記載された構成要素のそれぞれの範囲は他の構成要素と関連して強調できるので、本発明の多様な実施形態の理解増進を助ける。
【００１８】
添付の図面において、類似なレファレンス番号は、同一であるとか、または機能的に類似な構成要素に関連できる。このようなレファレンス番号は多様な実施形態を明確にするために詳細な説明で使われ、本発明の多様な例及び長所を説明することに使われる。方法ステップ及びシステム構成部は図面で有用なシンボルにより表現され、単に本発明の理解のために関連した特定の細部事項を表すことが分かる。また、この分野に属した当業者に容易に明白になる細部事項は開示しない。本文書で第１及び第２のような関連用語は、実際の関係や、エンティティ間の順序を暗示する必要なく、他のエンティティからあるエンティティを区別するために使用される。
【００１９】
本発明はＮＤＥＦ（NFC Data Exchange Format）で保安されたレコードを識別するための方法を提案する。本発明の第１実施形態において、署名ＲＴＤにより保安されるレコードのセットの開始は、開始／配置マーカ（Begin/Place Marker）署名レコードを使用して指示される。本発明の第２実施形態において、保安されたバイト（secured bytes）と呼ばれる新たなフィールドが署名ＲＴＤレコードに追加される。保安されたバイトフィールドは、署名ＲＴＤにより保護されるデータのバイトを識別するために使用することができる。このアプリケーションは、保安されたバイトフィールドを使用することにより、１つの署名ＲＴＤを使用してマルチプルレコード及びマルチプルＮＤＥＦメッセージからデータを保護する能力を有する。
【００２０】
図１は、一対のＮＦＣ装置の間の通信を図示している。前記装置は３個の互いに異なるアプリケーションモード（すなわち、ピア・トゥ・ピア（Peer-to-Peer）モード、リーダ／ライタ（Reader/Writer）モード、及びカードエミュレーションモード（Card Emulation）モード）で通信する。ピア・トゥ・ピアモードでは、ＮＦＣ装置の両方とも同様な能力を有することができ、前記装置の間の区別がない。リーダ／ライタモードにおいて、前記装置のうちの１つはリーダ／ライタの能力を有し、他の装置は単純なタグである。カードエミュレーションモードでは、装置のうちの１つはリーダであり、残りの他の装置は単純なタグまたはＮＦＣ装置となることができ、前記ＮＦＣ装置は保安メモリに格納されたレコード形態でクレジットカードの細部事項を格納する。
【００２１】
図２は、ＮＦＣ技術をサポートすることに要求される典型的なプロトコルスタックを図示している。アプリケーションデータは、ＮＤＥＦメッセージ形態でコード化されることができ、ＮＦＣリンクの上で転送できる。ＮＤＥＦフォーマットは、リーダ／ライタ動作モードだけでなく、ピア・トゥ・ピアモードでも使用できる。
【００２２】
図３は、ＮＤＥＦ構造を表現している。一番目のバイトは、多様なビットフィールドでＮＤＥＦメッセージのための制御情報を有する。ビットフィールドは、ＭＢ（Message Begin）フィールド、ＭＥ（Message End）フィールド、ＣＦ（Chunk Flag）フィールド、ＳＲ（Short Record）フィールド、ＩＬ（ID Length）フィールド、及びＴＮＦ（Type Name Format）フィールドである。タイプ、ＩＤ及びペイロードのための多様な長さ及び値が格納される。
【００２３】
図４は、NFC Forum-TS-RTD_Sisgnature_0.99に記述されたように、存在する署名ＲＴＤレコードの従来のペイロードを示している。図４を参照すると、バージョン（Version）フィールド４００は、仕様標準のメジャー（major）またはマイナーバージョンナンバー（minor version number）が記載されている。署名フィールド４０５は、保護されたＮＤＥＦデータのための署名を表すＴＬＶ構造を含んでいる。認証チェーン（Certificate Chain）フィールド４１０は、ＮＤＥＦメッセージの送信器の認証に使用される公認認証書のリストを提供する。
【００２４】
図５は、図４に示す署名ＲＴＤの署名フィールド（Signature Field）４０５のサブフィールドを示す。特に、署名フィールド４０５は、URI（Uniform Resource Identifier）_presentビットフィールド４１５、署名タイプフィールド４２０、署名長さフィールド４２５、及び署名／ＵＲＩフィールド４３０を含む。URI_presentビットフィールド４１５は、署名がレコード自体に含まれているか、または署名／ＵＲＩフィールド４３０により指示されたＵＲＩ（Uniform Resource Identifier）にあるかを表すことに使われる。
【００２５】
図６及び７は、本発明の実施形態に従って、修正された署名ＲＴＤレコードを示す。
【００２６】
図６を参照すると、修正された署名ＲＴＤレコードの一番目のバイトは図７のように３個のサブフィールド５１５、５２０、５２５を有する制御フィールド５００である。
【００２７】
図７を参照すると、制御フィールド５００、すなわちフラグ（Flag）フィールド５１５の一番目の２ビットは、前記署名ＲＴＤレコードが無欠性のためのレコードブロックの開始を表すことに使われるものであるか、認証保護が与えられたか、または前記レコードが署名フィールド５０５を有しているかを表すことに使われる。次に、２つのフィールド５２０、５２５は、各々３ビットフィールドとしてメジャーまたはマイナーバージョンを表記する。前記制御フィールド５００の一番目の２ビットは次のような値のうちの１つを取ることができる。
【００２８】
‘００’は、署名が今後に追加されるように、レコードブロックの初めを表す。これが配置マーカ署名レコードである。
【００２９】
‘１１’は、署名を有する署名レコードであり、‘０１’、‘１０’は今後の使用のための予備である。
【００３０】
図８は、本発明の実施形態に従って、ＮＤＥＦにおいて保全されるレコードを選択する第１方法を示す図である。図８を参照すると、開始／配置ホルダ署名ＲＴＤという名前のレコードはコード化されており、この署名ＲＴＤに後続するレコードが次の署名ＲＴＤまで保安されることをＮＤＥＦパーサに知らせている。したがって、レコードＲ３、Ｒ４、及びＲ５は、レコードＲ２に後続する署名ＲＴＤにより保護される。
【００３１】
図９は、本発明の実施形態に従って、署名ＲＴＤのための代案的な構造を示す。図９は、署名ＲＴＤにより保安されたデータが、情報のバイトを使用して示されている、署名ＲＴＤのための代案的な構造を表現している。
【００３２】
図９を参照すると、保安されたバイトフィールド８０５は、この署名ＲＴＤにおける署名により保安された署名ＲＴＤの該フィールドに先行するデータバイトの数を表している。
【００３３】
図１０は、本発明の実施形態に従って、ＮＤＥＦにおけるレコードを保安する第２方法を示す図である。図１０を参照すると、保安されたバイトフィールドは、署名ＲＴＤフィールドのレコードＲ４及びＲ５のサイズと同一な値に設定される。
【００３４】
図１１は、本発明の実施形態に従って、署名フィールドのサブフィールドを表現したものである。より詳しくは、図１１で開始または配置マーカレコードは、０に設定されたURI_presentまたは署名タイプフィールドを有する。前記タイプフィールドは、デジタル署名を生成するために使用される署名アルゴリズムに関する情報を与えるために使用可能な有効な値が列挙されているテーブルにおいて定められたインデックス値をとることができる。例えば、署名タイプ0x00は、配置マーカレコードを示すために使用されてもよい。
【００３５】
図１２は、本発明の一実施形態に従って、ＮＤＥＦで選択的にレコードを保安するための方法を示すフローチャートである。より詳しくは、図１２は、ＮＤＥＦで選択的にレコードを保安するための方法１１００を示す。
【００３６】
図１２を参照すると、ステップ１１０２で、前記方法１１００が開始される。ステップ１１０４で、配置マーカ署名レコードが定義される。配置マーカ署名レコードは、URI_presentフィールドを‘０’に設定し、署名長さフィールドを‘０’に設定することによって定義できる。‘０’に設定されたURI_presentフィールド及び‘０’に設定された署名長さフィールドの組み合わせが、配置マーカ署名レコードである。また、配置マーカ署名レコードは、署名ＲＴＤのバージョンフィールドをフラグ、メジャーナンバーバージョン、及びマイナーナンバーバージョンに分けることによって定義できる。前記フラグフィールドは、前記レコードが配置マーカ署名レコードまたは署名ＲＴＤであるかを表すことに使われる。追加に、配置マーカ署名レコードは、URI_presentフィールドを‘０’に設定し、署名タイプフィールドを所定の値に設定することによって定義してもよい。‘０’に設定されたURI_presentフィールド及び‘０’に設定された署名タイプフィールドの組み合わせが、配置マーカ署名レコードである。
【００３７】
ステップ１１０６で、配置マーカ署名レコードがＮＤＥＦメッセージに配置される。配置マーカ署名レコードは修正されたＲＴＤである。ＮＤＥＦの配置マーカ署名レコードに先行するレコードの第１セットは保安されない。本発明の実施形態では、前記ＮＤＥＦメッセージの開始までの配置マーカ署名レコードに先行するレコードの第１セットは保安されない。本発明の他の実施形態では、配置マーカ署名レコードに先行する署名ＲＴＤまでの、配置マーカ署名レコードに先行するレコードの第１セットが保安されない。
【００３８】
ステップ１１０８で、配置マーカ署名レコードに後続するレコードの第２セットは保安される。方法１１００は、同一のＮＤＥＦに一部のレコードを保安されていないままで維持する間、一部のレコードを保安するための柔軟性を提供する。その後、前記方法１１００は、ステップ１１１０で終了する。
【００３９】
前述した方法は、署名ＲＴＤの署名を変更することなく、ＮＤＥＦメッセージの保安されていないレコードを削除できる柔軟性を提供する。追加に、ＮＤＥＦメッセージの保安されていないレコードは署名ＲＴＤの署名を変更することなく修正できる。その上、ＮＤＥＦメッセージの保安されていないレコードは署名ＲＴＤの署名を変更することなく追加できる。前記の方法１１００は、下記の方法１を参照して細部的に説明する。
【００４０】
方法１：
【００４１】
署名ＲＴＤにより保安されたレコードのセットの開始を表記するために、開始／配置マーカ署名レコードが保安される一番目のレコードの前に追加される。３個の互いに異なるフィールド表現は、開始／配置マーカ署名レコードを定義することに使用できる。
【００４２】
（ｉ）制御フィールドを使用して開始／配置マーカ署名レコードを定義
【００４３】
署名ＲＴＤレコードは、２つのビットフラグフィールドを含むように修正される。該２ビットフィールドは現在の署名ＲＴＤレコードの一番目のバイトでコード化できる。該２ビットフラグフィールドにより取れる値は、次の通りである。
【００４４】
‘００’は、署名が今後に追加されるようにレコードブロックの開始を表す。これが配置マーカ署名レコードである。
【００４５】
‘１１’は、署名を有する署名レコードであり、‘０１’、‘１０’は今後の使用のために予約されている。
【００４６】
図６、図７、及び図８は、方法１で使用しうる構造の例を提供している。
【００４７】
署名ＲＴＤにより保安されたレコードのセットの開始を表記するために、開始／配置マーカ署名レコードは、００に設定された署名ＲＴＤの制御フィールド５００により保安された第１レコードの前に追加される。署名フィールド５０５は、単に配置マーカレコードであるので、該レコードでは省略してもよい。認証チェーンフィールド５１０は、付加的に該配置マーカレコード自体で規定しても良い。前記配置マーカレコードに認証チェーンフィールド５１０を置くことによって、受信機のＮＤＥＦパーサにある保安エンジンは、署名が算出される以前にメッセージを認証することができる。他の利点は、署名の生成はＮＤＥＦメッセージが読取される時に起こりうるということである。これは、追加された性能の向上を与えることができる。
【００４８】
‘１１’に設定されたフラグビットを有する署名ＲＴＤは、保安されるレコードのセットの以後に配置される。署名ＲＴＤは、無欠性保護のために受信機で検証されるであろう署名を有する。仮に、公認認証書の値が配置マーカ署名レコードで特定されていないならば、署名フィールドセットを有する後の署名ＲＴＤにおいて提供される。
【００４９】
（ii）署名フィールドの一番目のバイトを使用して開始／配置マーカ署名レコードを定義
【００５０】
開始／配置マーカ署名レコードを表現するための他の代案は、署名ＲＴＤの署名フィールド（Signature field）のサブフィールド４１５、４２０、４２５、４３０を使用することである。バージョンフィールド４００は、単にバージョンを表す用途に使われる。署名フィールド（Signature field）のサブフィールド４１５、４２０、４２５、４３０は、図５に図示されている。例えば、２つの署名サブフィールドの組み合わせを配置マーカレコードを表現するために使用してもよい。
【００５１】
１．署名フィールドの一番目のバイトは０に設定できる。これは一番目のビット、URI_presentフィールド４１５は０に設定され、署名タイプフィールド４２０は、例えば０といった所定の値に設定されることを意味する。これは、この署名レコードは有効な署名を有しないが、署名されなければならないか、保安されていないままで残しておかなければならないレコードを識別する専ら配置マーカとして使われる。このようなフォーマットにおいて、署名長さフィールド４２５、署名／ＵＲＩフィールド４３０が署名タイプフィールド４２０に後続する。図１１では、署名長さフィールド４２５及び署名／ＵＲＩフィールド４３０は署名ＲＴＤに存在していない。
【００５２】
２．一番目のビット、URI_Presentフィールド４１５は０に設定され、署名長さフィールド４２５は０に設定される（図５参照）。署名タイプフィールド４２０は、署名の生成に使われるデジタル署名アルゴリズムタイプを表す。認証チェーンフィールド４１０は付加的にあってもよい。配置マーカレコードの署名タイプ及び認証情報を提供することによって受信機におけるＮＤＥＦパーサの保安エンジンは、署名が算出される以前にメッセージを認証することができる。他の利点は、検証目的のために、署名生成はＮＤＥＦメッセージが読取された時に起こることができるということである。これは、追加的な性能向上を与えることができる。
【００５３】
署名タイプが、デジタル署名と一緒に使われた署名アルゴリズムを示すように設定された署名ＲＴＤは、保安されるレコードのセットの以後に配置される。この署名ＲＴＤは、無欠性保護のために受信機で検証されるべきレコードのセットのデジタル署名を有する。仮に、証明値が配置マーカ署名レコードで特定されていなければ、設定された署名フィールドを有する後の署名ＲＴＤに含まれている。
【００５４】
前記の２つの方法のうちの１つを使用することによって、配置マーカ／開始署名ＲＴＤレコードを表現することが可能である。配置マーカ署名ＲＴＤレコードのペイロードは、数バイトロング（bytes long）のみであり、したがって、それらはＮＤＥＦ仕様において定義されているように、ショートレコードとして設定できる（例えば、ＮＤＥＦヘッダのＳＲ＝１に設定、図３参照）。
【００５５】
開始／配置マーカ署名レコードの以前のレコードは、ＮＤＥＦメッセージの開始または他の署名ＲＴＤレコードに至るまで保安されない。これは、一部の大きいレコードまたは共用情報を含むレコードがデジタル署名を使用して保安されないことによってアプリケーションに与えられる追加的な利点である。例えば、図８で、レコードＲ１及びＲ２は、デジタル署名により保護されておらず、レコードＲ３、Ｒ４、及びＲ５は署名により保護されている。
【００５６】
図１３は、本発明の他の実施形態に従って、ＮＤＥＦのレコードを選択的に保安するための方法を示す流れ図である。図１３には、ＮＤＥＦのレコードを選択的に保安するための方法が示されている。
【００５７】
図１３を参照すると、ステップ１２０２で、前記方法１２００は開始される。ステップ１２０４で、secured_bytesフィールドは定義され、この署名ＲＴＤにより保安されたデータの識別に使われる。ステップ１２０６で、secured_bytesフィールドは、署名ＲＴＤにより保安された情報のバイト数に設定され、署名ＲＴＤに、データを保安するデジタル署名が追加される。認証を提供する認証チェーンは、署名ＲＴＤにまた追加される。secured_bytesフィールドは、前記署名ＲＴＤに先行する保安されるバイトの数を表す。ステップ１２０８で、署名ＲＴＤの保安されたバイトフィールドに先行するデータが、保安されたバイトフィールドの値に基づいて保安される。その後、前記方法１２００はステップ１２１０で終了する。前記方法１２００は、方法２を参照して下記で細部的に説明する。
【００５８】
方法２：
【００５９】
図９及び１０を参照すると、新たなフィールド、すなわち保安されたバイトフィールド８０５は、署名ＲＴＤレコードに付加される。このフォーマットにおけるバージョンフィールド８００は、使われた仕様のメジャー及びマイナーバージョンナンバーをだけを有することができる。保安されたバイトフィールド８０５は、該署名ＲＴＤにより保安された該フィールドの以前のデータバイトの数を表す整数値である。これは、現在のＮＤＥＦメッセージのデータだけを表してもよい。代案的に、保安されたバイトは、また現在のＮＤＥＦメッセージの外部にあるＮＤＥＦレコードのデータを含んでもよい。これは、この方法を使用することによる追加的な利点である。ＮＤＥＦパーサは、保安されたバイトフィールド８０５を読取って、署名レコードのこのフィールドに先行するデータの多くのバイトに署名アルゴリズムを適用する。また、署名ＲＴＤレコードのヘッダフィールドは、保安されたバイトに含まれる。
【００６０】
例えば、本発明の一実施形態に従うＮＤＥＦメッセージは、スマートポスターを表現することに使われる。スマートポスターは、典型的にテキストタイプの幾つかのレコード、オーディオ、ビデオデータ、ＵＲＩなどを含むＭＩＭＥタイプを有することができる。図８に示されているＮＤＥＦメッセージは、オーディオデータを有するレコードであるレコードＲ１と、イメージデータを有するレコードであるレコードＲ２と、を有するスマートポスターレコードであってもよい。このスマートポスターの生成器は、２，３の理由によりレコードＲ１及びＲ２をサインしないように選択できる。第１に、これらのオーディオ及びイメージレコードは、大きいレコードとなりうるので、署名の算出に時間がかかる。第２に、仮にこれらがサインされていなければ、それらの上にインストールされた公認認証書を有しない単純な装置でも、レコードＲ１、Ｒ２の情報を得ることができる。レコードＲ３、Ｒ４、及びＲ５は、ＵＲＩタイプ、認証される必要があるエンティティにより提供される価格情報が与えられるテキストとなることができる。したがって、上述の方法１を使用すると、このブロックの開始が、レコードＲ３の以前であってレコードＲ５であるレコードブロックの終端の以後に配置される開始／配置マーカ署名ＲＴＤレコードによりマークされ、署名フィールドと一緒に署名ＲＴＤが配置される。ＮＤＥＦパーサは適切にこのスマートポスターで情報を使用することができ、ここで、レコードＲ１及びＲ２は保安されず、署名生成の間使われない。レコードＲ３、Ｒ４、及びＲ５の内容はレコードＲ５に後続する署名ＲＴＤにある署名フィールドを使用して保安される。
【００６１】
図１４は、本発明の他の実施形態に従うＮＦＣ装置の内部構成を示すブロック構成図である。
【００６２】
図１４で、ＮＦＣメッセージ生成部１３００はＮＤＥＦフォーマットでＮＤＥＦメッセージを生成し、送信部１３１０は生成されたＮＤＥＦメッセージを送信する。
【００６３】
図１２を参照すると、ＮＦＣメッセージ生成部１３００は、ＮＤＥＦメッセージに配置マーカ署名レコードを配置する。配置マーカ署名レコードは修正された署名ＲＴＤであり、ＮＤＥＦに配置されている配置マーカ署名レコードの以前のレコードの第１セットは保安されない。その後、ＮＦＣメッセージ生成部１３００は、有効な署名を含む署名ＲＴＤを使用して配置マーカ署名レコードに後続するレコードの第２セットを保安する。送信部１３１０は、本発明の実施形態に従って生成されたＮＤＥＦメッセージを転送する。
【００６４】
図１３を参照すると、ＮＦＣメッセージ生成部１３００は、署名ＲＴＤのsecure_bytesフィールドを設定する。その後、ＮＦＣメッセージ生成部１３００は、secure_bytesフィールド値に基づいて、署名ＲＴＤのsecure_bytesフィールドの以前のＮＤＥＦメッセージのデータを保安する。secure_bytesフィールドは、前記署名ＲＴＤの署名により保安されているデータのバイト数を表している。送信部１３１０は、本発明の他の実施形態に従って、生成されたＮＤＥＦメッセージを転送する。
【００６５】
本発明の一実施形態が例示及び説明されたが、これは本発明を明確にするためのものであり、その利点はこの実施形態に限定されるのではない。多様な修正、変形、多様性、代替、及び同等のものが請求項に記載されたように本発明の精神及び範囲から逸脱することなく、この分野に属する当業者に明白になる。したがって、詳細な説明及び図面は制限的な機能よりは本発明の例示的な説明としてみなされる。
【符号の説明】
【００６６】
４００ バージョンフィールド
４０５ 署名フィールド
４１０ 認証チェーンフィールド
４１５ URI（Uniform Resource Identifier）_presentビットフィールド
４２０ 署名タイプフィールド
４２５ 署名長さフィールド
４３０ 署名／ＵＲＩフィールド
５００ 制御フィールド
５０５ 署名フィールド
５１５、５２０、５２５ サブフィールド
５１５ フラグフィールド
８０５ バイトフィールド
【特許請求の範囲】
【請求項１】
ＮＦＣデバイスにおいて、ＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法であって、
前記ＮＤＥＦメッセージに配置マーカ署名レコードを配置する過程と、
有効な署名を含んでいる署名ＲＴＤを使用して、前記配置マーカ署名レコードに後続するレコードの第２セットを保安する過程と、
を含み、
前記配置マーカ署名レコードは修正された署名ＲＴＤであり、
前記ＮＤＥＦに配置されている前記配置マーカ署名レコードに先行するレコードの第１セットは、保安されないことを特徴とするＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項２】
前記配置マーカ署名レコードに先行するレコードの第１セットは、前記ＮＤＥＦメッセージの開始まで、保安されていないものであることを特徴とする請求項１に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項３】
前記配置マーカ署名レコードに先行するレコードの第１セットは、前記配置マーカ署名レコードに先行する前記署名ＲＴＤまで、保安されていないものであることを特徴とする請求項１に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項４】
前記配置マーカ署名レコードを定義する過程をさらに含むことを特徴とする請求項１から３のいずれか一項に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項５】
前記配置マーカ署名レコードを定義する過程は、
URI_presentフィールドを‘０’に設定する過程と、
signature_lengthフィールドを‘０’に設定する過程と、
を含み、
前記署名レコードを表す、前記‘０‘に設定されたURI_presentフィールド及び前記‘０’に設定されたsignature_lengthフィールドの組み合わせは、配置マーカ署名レコードを表していることを特徴とする請求項４に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項６】
前記配置マーカ署名レコードを定義する過程は、
前記署名ＲＴＤのバージョンフィールドを、フラグフィールド、メジャーナンバーバージョンフィールド、及びマイナーナンバーバージョンフィールドに区分する過程を含み、
前記フラグフィールドは、前記レコードが配置マーカ署名レコード及び署名ＲＴＤのうちの１つであるかを表していることを特徴とする請求項４に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項７】
前記配置マーカ署名レコードを定義する過程は、
URI_presentフィールドを‘０’に設定する過程と、
signature_typeフィールドを所定の値に設定する過程と、
を含み、
前記署名レコードを表す、前記‘０’に設定されたURI_presentフィールド及び前記所定の値に設定されたsignature_typeフィールドの組み合わせは、配置マーカ署名レコードを表していることを特徴とする請求項４に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項８】
前記ＮＤＥＦメッセージにおける保安されていないレコードを、前記署名ＲＴＤの署名を変更すること無く削除する過程をさらに含むことを特徴とする請求項１から７のいずれか一項に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項９】
前記ＮＤＥＦメッセージにおける保安されていないレコードを、前記署名ＲＴＤの署名を変更すること無く修正する過程をさらに含むことを特徴とする請求項１から７のいずれか一項に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項１０】
前記ＮＤＥＦメッセージにおける保安されていないレコードを、前記署名ＲＴＤの署名を変更すること無く追加する過程をさらに含むことを特徴とする、請求項１から７のいずれか一項に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項１１】
請求項１から１０のいずれか１つまたは複数で記述された方法を実施するための電子装置。
【請求項１２】
ＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法であって、
署名ＲＴＤのsecure_bytesフィールドを設定する過程と、
前記secure_bytesフィールドの値に基づいて、前記署名ＲＴＤの前記secure_bytesフィールドに先行するＮＤＥＦメッセージのデータを保安する過程と、
を含み、
前記secure_bytesフィールドは、前記署名ＲＴＤが備えている署名により保安されたデータのバイト数を表していることを特徴とするＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項１３】
ＮＤＥＦメッセージにおけるレコードを選択的に保安するためのＮＦＣ装置であって、
ＮＤＥＦメッセージに配置マーカ署名レコードを配置するＮＦＣメッセージ生成部と、
前記生成されたＮＤＥＦメッセージを送信する送信部と、
を含み、
前記配置マーカ署名レコードは、修正された署名ＲＴＤであり、
前記配置マーカ署名レコードに先行するレコードの第１セットは保安されず、
有効な署名を含んでいる署名ＲＴＤを使用して、前記配置マーカ署名レコードに後続するレコードの第２セットは保安されることを特徴とするＮＤＥＦメッセージにおけるレコードを選択的に保安するための装置。
【請求項１４】
ＮＤＥＦメッセージにおけるレコードを選択的に保安するためのＮＦＣ装置であって、
署名ＲＴＤのsecure_bytesフィールドを設定するＮＦＣメッセージ生成部と、
生成されたＮＤＥＦメッセージを送信する送信部と、
を含み、
前記secure_bytesフィールドは、前記署名ＲＴＤの署名により保安されたデータのバイト数を表しており、該secure_bytesフィールドの値に基づいて、前記署名ＲＴＤの前記secure_bytesフィールドに先行するＮＤＥＦメッセージのデータを保安することを特徴とするＮＤＥＦメッセージにおいるレコードを選択的に保安するための装置。
【請求項１】
ＮＦＣデバイスにおいて、ＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法であって、
前記ＮＤＥＦメッセージに配置マーカ署名レコードを配置する過程と、
有効な署名を含んでいる署名ＲＴＤを使用して、前記配置マーカ署名レコードに後続するレコードの第２セットを保安する過程と、
を含み、
前記配置マーカ署名レコードは修正された署名ＲＴＤであり、
前記ＮＤＥＦに配置されている前記配置マーカ署名レコードに先行するレコードの第１セットは、保安されないことを特徴とするＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項２】
前記配置マーカ署名レコードに先行するレコードの第１セットは、前記ＮＤＥＦメッセージの開始まで、保安されていないものであることを特徴とする請求項１に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項３】
前記配置マーカ署名レコードに先行するレコードの第１セットは、前記配置マーカ署名レコードに先行する前記署名ＲＴＤまで、保安されていないものであることを特徴とする請求項１に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項４】
前記配置マーカ署名レコードを定義する過程をさらに含むことを特徴とする請求項１から３のいずれか一項に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項５】
前記配置マーカ署名レコードを定義する過程は、
URI_presentフィールドを‘０’に設定する過程と、
signature_lengthフィールドを‘０’に設定する過程と、
を含み、
前記署名レコードを表す、前記‘０‘に設定されたURI_presentフィールド及び前記‘０’に設定されたsignature_lengthフィールドの組み合わせは、配置マーカ署名レコードを表していることを特徴とする請求項４に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項６】
前記配置マーカ署名レコードを定義する過程は、
前記署名ＲＴＤのバージョンフィールドを、フラグフィールド、メジャーナンバーバージョンフィールド、及びマイナーナンバーバージョンフィールドに区分する過程を含み、
前記フラグフィールドは、前記レコードが配置マーカ署名レコード及び署名ＲＴＤのうちの１つであるかを表していることを特徴とする請求項４に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項７】
前記配置マーカ署名レコードを定義する過程は、
URI_presentフィールドを‘０’に設定する過程と、
signature_typeフィールドを所定の値に設定する過程と、
を含み、
前記署名レコードを表す、前記‘０’に設定されたURI_presentフィールド及び前記所定の値に設定されたsignature_typeフィールドの組み合わせは、配置マーカ署名レコードを表していることを特徴とする請求項４に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項８】
前記ＮＤＥＦメッセージにおける保安されていないレコードを、前記署名ＲＴＤの署名を変更すること無く削除する過程をさらに含むことを特徴とする請求項１から７のいずれか一項に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項９】
前記ＮＤＥＦメッセージにおける保安されていないレコードを、前記署名ＲＴＤの署名を変更すること無く修正する過程をさらに含むことを特徴とする請求項１から７のいずれか一項に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項１０】
前記ＮＤＥＦメッセージにおける保安されていないレコードを、前記署名ＲＴＤの署名を変更すること無く追加する過程をさらに含むことを特徴とする、請求項１から７のいずれか一項に記載のＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項１１】
請求項１から１０のいずれか１つまたは複数で記述された方法を実施するための電子装置。
【請求項１２】
ＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法であって、
署名ＲＴＤのsecure_bytesフィールドを設定する過程と、
前記secure_bytesフィールドの値に基づいて、前記署名ＲＴＤの前記secure_bytesフィールドに先行するＮＤＥＦメッセージのデータを保安する過程と、
を含み、
前記secure_bytesフィールドは、前記署名ＲＴＤが備えている署名により保安されたデータのバイト数を表していることを特徴とするＮＤＥＦメッセージにおけるレコードを選択的に保安するための方法。
【請求項１３】
ＮＤＥＦメッセージにおけるレコードを選択的に保安するためのＮＦＣ装置であって、
ＮＤＥＦメッセージに配置マーカ署名レコードを配置するＮＦＣメッセージ生成部と、
前記生成されたＮＤＥＦメッセージを送信する送信部と、
を含み、
前記配置マーカ署名レコードは、修正された署名ＲＴＤであり、
前記配置マーカ署名レコードに先行するレコードの第１セットは保安されず、
有効な署名を含んでいる署名ＲＴＤを使用して、前記配置マーカ署名レコードに後続するレコードの第２セットは保安されることを特徴とするＮＤＥＦメッセージにおけるレコードを選択的に保安するための装置。
【請求項１４】
ＮＤＥＦメッセージにおけるレコードを選択的に保安するためのＮＦＣ装置であって、
署名ＲＴＤのsecure_bytesフィールドを設定するＮＦＣメッセージ生成部と、
生成されたＮＤＥＦメッセージを送信する送信部と、
を含み、
前記secure_bytesフィールドは、前記署名ＲＴＤの署名により保安されたデータのバイト数を表しており、該secure_bytesフィールドの値に基づいて、前記署名ＲＴＤの前記secure_bytesフィールドに先行するＮＤＥＦメッセージのデータを保安することを特徴とするＮＤＥＦメッセージにおいるレコードを選択的に保安するための装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公表番号】特表２０１１−５２７８４９（Ｐ２０１１−５２７８４９Ａ）
【公表日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願番号】特願２０１１−５１７３４６（Ｐ２０１１−５１７３４６）
【出願日】平成２１年７月７日（２００９．７．７）
【国際出願番号】ＰＣＴ／ＫＲ２００９／００３７１８
【国際公開番号】ＷＯ２０１０／００５２２８
【国際公開日】平成２２年１月１４日（２０１０．１．１４）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
【公表日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願日】平成２１年７月７日（２００９．７．７）
【国際出願番号】ＰＣＴ／ＫＲ２００９／００３７１８
【国際公開番号】ＷＯ２０１０／００５２２８
【国際公開日】平成２２年１月１４日（２０１０．１．１４）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
[ Back to top ]