NFCで偽造品対策を始めるには、認証システムの自社開発が必要？

顧客向けのNFC認証サービスには、商品に合うタグ、安全な設定、商品情報との関連付け、読み取り情報を検証するサーバーが必要です。タグに設定する内容とサーバーの検証ルールを合わせることで、実際に使える仕組みになります。

BrandGuard™の包括的なNFC保護サービスでは、タグ製造、セキュアエンコード、オンライン検証を、合意した範囲でまとめて提供します。NTAG® 424 DNAを採用するために、ブランドが認証基盤を一から開発・運用する必要はありません。

顧客は対応するNFCスマートフォンをタグにかざし、端末の案内に従ってブラウザーを開きます。専用アプリや認証コードの手入力は不要で、結果をオンラインで確認できます。

すでに自社の検証システムがある場合は、タグ供給とセキュアエンコードを、そのシステムの設定に合わせて検討できます。ここで扱うのは、オンライン検証もBrandGuard™に任せるサービスです。

同じブランドが、よく似たボトルで2種類の香水を販売しているとします。タグ自体が本物でも、別の香水の情報を表示してしまえば、顧客を誤解させます。認証の正確さを考えるとき、チップだけを見ていては足りません。

BrandGuard™のセキュアエンコードは、URLを書き込むだけの作業ではありません。案件の仕様に従ってタグごとの認証用情報を設定し、タグの識別情報を対応する商品記録に関連付けます。オンラインでは、認証情報と登録済みの商品との関係を確認します。

タグ供給、書き込み、検証サーバーをつなぐことで、顧客が手元の商品と照らし合わせられる情報を提供します。ただし、システムが確認できるのは、登録されたタグと商品情報の対応です。元の商品情報が誤っていたり、別の商品にタグを付けたりすれば、システムが自動で誤りを修正することはできません。製造・納品時の商品情報と取り付けの確認も欠かせません。

一般的なNFCタグでもブランドの公式サイトは開けます。その固定URLを別のタグにコピーすれば、同じページが開く場合もあります。ブランドのロゴが表示されたことや、番号がデータベースに存在したことだけでは、タグの認証にはなりません。

適切に設定したNTAG® 424 DNAは、読み取り時にAES-128暗号技術で保護された認証情報を生成できます。BrandGuard™はその情報をサーバーで検証し、登録されたタグと商品との関係も確認します。公開された番号や固定URLをコピーするだけでは、同じように有効な新しい認証情報は作れません。

検証はBrandGuard™のサーバーで行います。公開ページに検証用の鍵を置いたり、書き換え可能なURLの値からページ側が成功と判断したりする必要はありません。画面に表示する結果は、サーバーによる認証情報の検証に基づきます。

正規品に付いたタグを読み取った人が、そのリンクを誰かに送ったとします。受け取った人は商品説明を読めるかもしれません。しかし、その人が持つ別の商品まで、今認証されたことにはなりません。

対策には二つの段階があります。一つは、古い読み取り情報の再送への対策です。検証サービスは読み取りカウンターと受け付け済みの記録を照合し、同じ情報を新たな認証として扱わないようにします。ただし、これですべての攻撃を防げるわけではありません。まだサーバーに送られていなかった有効な情報の場合、カウンターだけでは、そのリンクを開いた人が、その時点でタグを手元に持っているかまでは確認できません。

もう一つは、認証後のページのコピーや更新への対策です。ProofWidgetでは、有効期間が短く、一度だけ使える認証用情報によって、対応する公式結果をBrandGuard™から取得します。通常の商品URLだけで新しい認証は発生せず、使用済みの情報から繰り返し新たな成功結果を取得することもできません。

前者はタグの読み取り情報を、後者はウェブページでの結果の受け取りを守ります。商品情報は共有できても、別の商品に新たな認証結果まで引き継がせないための区別です。

スマートフォンでタグを読み取れないことも、途中で通信が切れることもあります。この場合は認証のための情報が足りません。情報が足りないまま認証成功と表示することはできませんし、確認できなかっただけで偽物と判断するのも適切ではありません。

有効な認証用情報がない場合、公式パネルは認証成功を示さない中立の状態を表示します。ブックマークから商品ページを開いた場合も、新たにNFCを読み取ったわけではありません。商品説明やサポートは利用できても、今認証が行われたようには見せません。

届いた認証情報が検証を通らなかった場合は、タグからの情報の正当性を確認できていないため、成功とは表示できません。再読み取りやブランドへの問い合わせなど、次に取れる行動を分かりやすく案内する必要があります。具体的な表示は、案件で有効にする公式の状態表示に従います。

包装の状態とタグの認証も区別します。顧客が本物の商品を自分で開封すれば、対応する封緘タグは開封状態を示しても、タグの認証自体は通る場合があります。この違いを伝えることで、異常への注意を促しながら、正規購入者の不安も抑えられます。

暗号技術で確認するのはタグからの認証情報です。そのタグが本物の商品から取り外されたかどうかまで、単独で判断できるわけではありません。認証結果を実物の保護につなげるには、タグの材料や取り付け方も重要です。

BrandGuard™では、セキュアNFCラベル、開封検知シール、熱圧着式の衣類用バッジなどを提供しています。きれいに剥がして再利用されるリスクには、剥離時に壊れやすい材料や固定構造を検討します。開封を確認したい場合は、実際に開ける場所を封緘する必要があります。

接着面、液体、金属、洗濯、摩耗などによって適切な設計は変わります。読み取り性能と取り付け方は、実際の商品で確認する必要があります。また、タグでボトル内の成分を検査することはできません。物理的な保護とオンライン検証の両方を考慮して設計します。

確認が終わった後も、顧客との接点は続きます。BrandGuard™が提供する結果ページを使う方法のほか、検証に成功した顧客を承認済みのブランドサイトや商品ページへ案内する方法があります。そこで使用方法、ブランドの紹介、公式ストア、アフターサービスを提供できます。

ProofWidgetは、BrandGuard™の検証結果を自社サイトに表示する埋め込みパネルです。商品情報やページ全体の構成はブランドが管理します。パネル内には、BrandGuard™が提供する検証結果と時刻を表示し、対応する場合は包装の状態も表示します。対応する検証の結果を示すためのものであり、常に「認証済み」と表示する画像とは異なります。

パネルの状態と文言はBrandGuard™が管理します。ブランドはサイトのコンテンツを運営し、認証の成否や結果表示のルールを自ら実装する必要はありません。会員、ポイント、注文管理などとの連携は、別途合意する範囲です。

ProofWidgetのコア機能と組み込み例は用意されていますが、最初から有効になっているわけではありません。導入先のブランドサイトでは、ドメインの確認、ページへの組み込み、明示的な有効化、実際のスマートフォンとブラウザーでの導入時の動作確認が必要です。コードの実装と各社サイトでの本番稼働は別の段階です。

ProofWidgetの導入では、ブランドが対象ドメインを管理していることを確認し、対象のHTTPSサイトと遷移先を承認します。認証後のアクセスを、事前に確認した行き先に限定するためです。別のサイトにコンポーネントをコピーするだけでは、そのサイトで利用できるようにはなりません。

導入規定では、認証用情報や保護対象の商品情報を、アクセス解析や画面操作の録画ツールに収集させないことを求めています。認証に使う情報が無関係なツールに渡らないよう、公開前にも確認します。

導入時には、リンクのコピー、ページ更新、認証用情報の期限切れ、未承認サイト、結果を取得できない場合の動作も確認します。有効な結果がない場合は、商品ページを使える状態に保ち、認証成功を示さない中立の表示にします。これらは実際の導入先で確認すべき事項で、デモで一度成功しただけでは本番での動作を保証できません。