NFC タグのパスワード保護と永久ロック: 導入前に何を選択するか

NFC タグが公開展開または顧客向けの展開で使用される場合、コンテンツが誤って編集可能なままになってはいけません。{0}ただし、「タグをロックする」にはいくつかの異なる意味があり、間違ったものを選択すると、制作後に修正できない問題が発生する可能性があります。

実際の決定は、タグを書き込み可能のままにするか、保護されたメモリ操作にパスワードを必要とするか、それとも永続的に読み取り専用にするかです。- 4 番目の質問は、その選択肢の外にあります。プロジェクトで物理タグが本物であることを証明する必要がある場合、単純なパスワード保護や読み取り専用ロックだけでは十分ではありません。-

このガイドは、一括展開用に NFC ステッカー、ラベル、カード、ディスプレイ、その他の携帯電話で読み取り可能なタグを準備する B2B チームを対象としています。{1}アプリ固有のプログラミング手順ではなく、デプロイメントの決定、実稼働シーケンス、受け入れ基準に重点を置いています。{3}}

 

4 つの異なる要件が「セキュリティ」と呼ばれることが多い

これらは交換可能ではありません。永久にロックされた URL は、コピーして別の通常のタグに複製することができます。パスワードを使用すると、パブリック NDEF URL を暗号化せずに、一部のメモリ操作を制限できます。安全な認証プロジェクトでは引き続き NDEF URL を使用する可能性がありますが、セキュリティの価値は、タグが読み取り専用であるという事実からではなく、暗号化プロトコルとバックエンドの検証から得られます。-

まず広範な NFC の基本が必要な場合は、Syntek のNFC タグの基礎ガイドその導入タスクを所有しています。このページは、タグのコンテンツと展開ワークフローがすでに存在する時点から始まります。

 

 

一般的な NTAG21x タグにおける永続的ロックの意味

NXP は、NTAG213、NTAG215、および NTAG216 を、両方の機能を備えた NFC フォーラム タイプ 2 タグ準拠の IC として説明しています。フィールド-プログラム可能な読み取り専用-ロック機能そして設定可能な32ビットパスワード保護。これらは別のメカニズムです。

でNTAG213/215/216 データシート静的ロック バイトと動的ロック バイトは、定義されたユーザー メモリ ページを再度書き込めるかどうかを制御します。-関連するロック ビットが設定されると、保護領域は読み取り専用になります。-。ロックビットのプロセスは一方向です。プログラムされたロックビットを単純に 1 から 0 に戻すことはできません。-

このため、永久ロックはエンコードの開始時ではなく、承認プロセスの終了時に行われます。

のChrome ウェブ NFC ドキュメントは、サポートされているタグに対して同じ操作コンセプトを使用します。つまり、タグを読み取り専用にすることは永続的な一方向の操作であり、通常の NDEF ワークフローでは元に戻すことはできません。{0}}

 

パスワード保護は暗号化ではなく、元に戻せる制御です

NTAG21x は、構成可能なパスワード保護も提供します。 NXP は、パスワード-認証コマンド、保護領域の開始点、書き込み操作、または構成に応じて読み取りおよび書き込み操作を制限できるアクセス設定を文書化しています。-

これにより、承認されたオペレータが後で保護されたコンテンツを変更する必要がある場合に、パスワード ベースの制御が役立ちます。{0}

ただし、32 ビットのタグ パスワードを暗号化または高セキュリティ認証として販売することはできません。-これはメモリ操作のアクセス制御機能です。-タグに誰でも読み取れる公開 URL が含まれている場合、書き込みをパスワードで保護しても、その URL は機密になりません。

また、運用上の依存関係も生じます。パスワード、発行手順、回復ポリシー、およびタグの認証と更新に使用されるツールを誰かが所有する必要があります。この制御を失うと、理論的には書き換え可能なデプロイメントが、実質的に保守不可能なデプロイメントに変わってしまう可能性があります。

 

導入ライフサイクルを使用してロック戦略を選択する

最も保守しやすいパブリック デプロイメントは、多くの場合、安定した会社管理の URL をタグに書き込み、その後にサーバー側のコンテンツを変更することです。-このモデルでは、ランディング ページ、キャンペーン コンテンツ、保証情報、製品情報はオンラインで編集可能なままですが、NFC メモリは読み取り専用になる可能性があります。-

シンテックのウェブサイト NFC タグガイドURL{0}} ベースの NFC 導入に関する別の質問について説明します。ここでのロックの決定は、宛先アーキテクチャが承認された後に開始されます。

 

移行計画なしにベンダー所有の移行先を永久にロックしないでください。{0}

永久ロックは、インターネット上で起こっていることではなく、チップに保存されているものを凍結します。この区別は、組織が移行先を制御している場合、または信頼できる移行パスがある場合にのみ役立ちます。

タグを URL にロックする前に、次のことを確認してください。

• ドメインの所有者。
• リダイレクトを制御するのは誰か。
• 宛先が後で別のプラットフォームに移動できるかどうか。
• URL に、消失する可能性のあるベンダー固有のパスが含まれているかどうか。{0}
• タグごとの一意のトークンが、予想される展開期間中有効である必要があるかどうか。-
• キャンペーン、従業員、製品レコード、または場所が退職するとどうなるか。

使い捨ての SaaS URL を指す永続的なタグは、一時的なソフトウェアの決定を永続的に物理的にリマインダーにすることができます。有効期間の長いタグの場合、URL の制御を製品仕様の一部として扱う必要があります。-

 

 

ロックはエンコーディングと機能の承認に従う必要があります

安全な生産シーケンスを分離する書き込み, 検証そしてロックする.

1. ペイロード ルールを凍結します。正確な NDEF レコード タイプ、URL 構造、一意のトークン ルール、および変数データを定義します。-
2. タグをエンコードします。指定された制作プロセスを使用して、承認されたペイロードを書き込みます。
3. 電子的に読み直してください。保存されたレコードがソース データと一致することを確認します。
4. ユーザーの結果をテストします。代表的なターゲット電話機またはリーダーで完成したタグをタップし、意図したアクションが完了したことを確認します。
5. 目的地を確認してください。リダイレクト、HTTPS の動作、アカウントの所有権、および固有のマッピングを確認します。
6. 実稼働版と同等のサンプルを承認します。{0}サンプルでは、​​最終的なチップ、インレイ、材質、表面状態、およびエンコーディング ルールを使用する必要があります。
7. 承認された保護状態を適用します。プロジェクトの仕様に従って、書き込み可能のままにするか、パスワード制御を構成するか、永続的にロックします。
8. ロック後の状態を確認します。-コンテンツをもう一度読んで、意図した書き込み制限が実際に適用されていることを確認してください。
9. 結果を記録します。マッピング、サンプル リビジョン、ロック状態の要件を本番環境の記録に記録します。{0}

この順序により、タグがすでに永続的に読み取り専用になった後にのみ、間違った URL、重複したトークン、または間違った NDEF レコードが見つかるという、よくある失敗を防ぐことができます。-

 

 

固有の URL の場合、マッピング ファイルはロック状態と同じくらい重要です

NFC タグのバッチには共通の URL が含まれる場合もあれば、各部分に異なるトークンが含まれる場合もあります。独自のエンコーディングにより、別の障害モードが追加されます。NFC タグは正しくロックされているものの、間違った物理アイテムにマッピングされている可能性があります。

ピースごとのエンコードの場合、本番レコードには次のようなフィールドが必要になる場合があります。{0}

ロックしても不正なマッピングは修正されません。正しい順序は、最初にマッピングを検証し、次に不可逆状態を適用することです。

 

タグが永続的に読み取られた後にテストする内容-のみ

最終検査では、コンテンツがまだ機能していることと、承認された保護状態が存在していることの両方を証明する必要があります。

大量の注文の場合、すべてのエンコードされたアイテムまたは統計的に管理されたサンプルを各レイヤーでチェックするかどうかを定義します。そのサンプリング計画は購入者と製造者の契約です。タグが「テストされている」という曖昧な記述に置き換えるべきではありません。

 

永続的なロックでは物理的な改ざんは解決されません

読み取り専用の NFC タグは通常のメモリ操作では書き換えることができませんが、公開タグは削除、カバー、交換、または物理的な損傷を受ける可能性があります。{0}

公共施設の場合は、プロジェクトに以下も必要かどうかを検討してください。

• 改ざん防止構造。-
• 定期的な物理的検査。
• 印刷された QR フォールバック。
• 管理資産/位置登録簿。
• 予期しない宛先またはトークンの使用に対するバックエンドの監視。
• タグが破損または紛失した場合の交換手順。

物理的なセキュリティ要件は環境によって異なります。カウンタートップのレビュー タグ、屋外資産ラベル、製品認証シールには、同じ脅威モデルがありません。-

 

パスワード保護は認証の代わりではありません

この区別は、偽造防止プロジェクトにおいて最も重要です。{0}

標準タグは永続的にロックできるため、そのメモリは編集できませんが、表示または読み取り可能なデータは別のタグにコピーできます。固定 UID は識別子として役立ちますが、識別子のみに依存することは暗号的な証明と同等ではありません。

ビジネス要件が「不正な書き換えの防止」である場合は、ロックまたはパスワード ベースの書き込み制御が適切である可能性があります。{0}要件が「この物理製品が本物であることを証明する」である場合、プロジェクトは認証用に設計されたチップとバックエンドを評価する必要があります。

そのセキュリティ アーキテクチャは、意図的にこの記事の範囲外にあります。ロック状態を変更するだけで、低コストのパブリック URL タグを「偽造防止」製品に変えないでください。-

 

生産後ではなく、RFQ でロック状態を定義する

携帯電話で読み取り可能な NFC タグとラベルを直接調達するには、{0}Syntek のNFCタグカテゴリ商業所有者です。プロジェクトで社内でのエンコードと検証が必要な場合、-NFCリーダー＆ライター部門は関連するハードウェア パスです。

 

再注文にはロック{0}}状態変更-制御ルールが必要です

繰り返し注文では、何が同じでなければならないかを定義せずに、「同じ」という単語を継承してはなりません。

変更が以下に影響を及ぼす場合、再検証を検討する必要があります。

• チップモデルまたはメモリ/保護動作。
• NDEF レコード タイプまたは URL 構造。
• 共通エンコーディングと独自エンコーディング。
• パスワード設定または保護範囲。
• 永久ロックポリシー。
• 印刷されたシリアルまたは QR マッピング。
• インレイ、アンテナ、または完成した素材。
• 取り付け面または対象の電話機/リーダー セット。

装飾的なアートワークの変更には完全な技術的な再テストは必要ありませんが、RF の動作、データ解釈、マッピング、または書き込み保護を変更する可能性のある変更は、影響を受けるレイヤーのレビューをトリガーする必要があります。

 

決定ルール

「安全」という言葉ではなく、メンテナンス モデルから保護状態を選択します。

タグを書き込み可能にしておくデプロイメントがまだ試行中である間。パスワードで制御されたアクセスを使用する-許可された将来のメモリ更新が実際の動作要件であり、選択されたチップが必要な動作をサポートしている場合。永続的な読み取り専用ロックを使用する-エンコードされたペイロードが最終的なものであり、書き換えるべきではない場合。暗号化認証を使用する企業が単に通常の編集を阻止するのではなく、信頼性を検証する必要がある場合。

大量生産の場合、最も安全な順序は次のとおりです。

ペイロードの定義 → エンコード → リードバック → 宛先のテスト → マッピングの検証 → 完成したサンプルの承認 → 保護の適用 → 保護の検証 → バッチのリリース

このシーケンスにより、不可逆的なロックが不可逆的な製造ミスになるのを防ぎます。