کلیدهای NFC برای سیستم های عضویت: UID، NDEF و نقشه برداری اعضا

یک کلید NFC می تواند یک عضو را شناسایی کند، یک تجربه وب را باز کند یا هر دو را انجام دهد. اشتباه این است که با آن‌ها به‌عنوان یک گردش کار فنی برخورد کنیم.

در یک برنامه عضویت یا وفاداری، سوال اصلی این نیست که چه تراشه NFC را بخریم. هستسیستم به کدام شناسه اعتماد می کند، رکورد عضو در کجا زندگی می کند، و چگونه کلید فیزیکی بدون شکسته شدن این نقشه صادر، جایگزین، غیرفعال و تخصیص مجدد می شود..

این راهنما بر روی آن معماری داده تمرکز دارد. این برای اپراتورهای سالن بدنسازی، باشگاه‌ها، پلتفرم‌های وفاداری، عضویت-یکپارچه‌سازان سیستم و تیم‌های تدارکاتی است که برنامه‌ریزی استقرار انبوه کلید NFC را دارند.

 

با تراکنش عضویت شروع کنید، نه با کلید فوب

یک جا کلیدی NFC یک اعتبار است. امتیازها را محاسبه نمی‌کند، تصمیم نمی‌گیرد که آیا عضویت فعال است یا خیر، نمایه مشتری معتبر را ذخیره نمی‌کند، یا قوانین تجاری را به تنهایی اعمال نمی‌کند.

یک تعامل عضویت معمولاً یکی از دو مسیر را دنبال می کند:

مسیر خواننده اختصاصی-:
عضو ← کلید NFC ← خواننده سازگار ← شناسه اعتبار ← نرم افزار عضویت ← سابقه عضو ← ورود-ورود / مزایا / مجوز

مسیر ضربه-تلفن:
عضو ← کلید NFC ← گوشی هوشمند ← آدرس اینترنتی NDEF ← وب یا برنامه پشتیبان → حساب کاربری یا سابقه کمپین → اقدام عضویت

این مسیرها می توانند از همان فاکتور فرم فیزیکی استفاده کنند، اما الزامات فنی یکسانی ندارند.

اگر پروژه عمدتاً به جای شناسایی عضویت، دسترسی به در باشد، نیاز کنترل کننده سیستم دسترسی نصب شده است. Syntekراهنمای سازگاری فوب کلید مجاورتیآن وظیفه کاربر متفاوت را پوشش می دهد.

 

UID، NDEF و ID Member سه چیز متفاوت هستند

پروژه های عضویت اغلب با شکست مواجه می شوند زیرا چندین شناسه به عنوان قابل تعویض در نظر گرفته می شوند.

انجمن NFC تعریف می کندNDEFبه عنوان یک قالب رایج برای داده های برنامه در دستگاه ها و برچسب های سازگار با انجمن NFC{0}}. یک رکورد NDEF می‌تواند یک URI یا یک بار کاربردی دیگر را حمل کند، اما معنای تجاری آن رکورد متعلق به برنامه‌ای است که پشت آن قرار دارد.

NXP هااسناد NTAG213/215/216تأیید می‌کند که خانواده NTAG21x از رفتار برچسب‌های انجمن NFC نوع 2، ISO/IEC 14443 نوع A و ساختارهای داده NDEF پشتیبانی می‌کند. همچنین یک UID برنامه ریزی شده سازنده- ارائه می دهد. این قابلیت‌ها مفید هستند، اما همچنان لایه‌های مختلفی را نشان می‌دهند: UID برای هویت تراشه، NDEF برای داده‌های برنامه، و سوابق باطن برای منطق عضویت.

 

یکی از سه معماری عضویت را انتخاب کنید

1. خواننده اختصاصی + نقشه برداری اعتبار

در این مدل، اپراتور هر فوب کلید را به عنوان اعتبار سیستم صادر می کند. یک خواننده سازگار، شناسه یا داده های برنامه مورد انتظار پلت فرم عضویت را ضبط می کند. باطن این اعتبار را به یک رکورد عضو نشان می دهد.

این معماری متناسب با چک کردن مکرر-ورود به باشگاه، قفسه‌ها، شناسایی وفاداری با کمک کارکنان-و سایر نقاط تماس مدیریت‌شده که در آن اپراتور خواننده را کنترل می‌کند.

سوالات مهم عبارتند از:

• خواننده نصب شده کدام تراشه یا فناوری اعتبار را پشتیبانی می کند؟
• نرم‌افزار کدام مقدار را ثبت می‌کند: UID، شماره کارت، داده‌های بخش/فایل، یا شناسه تعریف‌شده دیگر{0}}سیستم؟
• آیا یک عضو می تواند بیش از یک اعتبار فعال داشته باشد؟
• آیا می توان اعتبارنامه را مستقل از حساب عضو غیرفعال کرد؟
• فوب های گم شده، برگردانده یا تعویض شده چگونه مدیریت می شوند؟

ممکن است NDEF در این معماری بی ربط باشد. یک فوب کلید می‌تواند یک اعتبار عضویت معتبر باشد، حتی زمانی که نیازی به URL قابل خواندن تلفن نیست.

2. روی تلفن + URL NDEF ضربه بزنید

در اولین تجربه عضویت{0} تلفن، کلید کلید معمولاً دارای یک URI NDEF است که به صفحه وب، جریان فعال‌سازی، پورتال حساب، صفحه وفاداری یا مسیر برنامه اشاره می‌کند.

رانمای فنی انجمن NFCبرچسب‌های انجمن NFC را به عنوان حامل پیام‌های NDEF توصیف می‌کند که می‌توانند اقداماتی مانند باز کردن پیوند اینترنتی را آغاز کنند. اپل همچنین خواندن تگ NFC پس‌زمینه را در اطراف سوابق NDEF URI در آیفون‌های پشتیبانی شده ثبت می‌کندهسته NFC.

برای این معماری، یک URL منحصربه‌فرد معمولاً باید حاوی یک رمز یا شناسه پروژه غیرشفاف باشد نه اینکه نام، ایمیل، موجودی یا سایر داده‌های شخصی غیرضروری یک عضو را مستقیماً در برچسب نشان دهد.

سپس پشتیبان وب می تواند آن توکن را در رکورد مناسب حل کند و تصمیم بگیرد که کاربر مجاز است چه چیزی را ببیند یا انجام دهد.

3. خواننده ترکیبی + تعامل تلفن

برخی از پروژه‌ها یک فوب کلیدی می‌خواهند تا از گردش کار خواننده مدیریت‌شده و تجربه ضربه-تلفن پشتیبانی کند.

این می تواند مفید باشد، برای مثال، زمانی که یک باشگاه بدنسازی از یک خواننده اختصاصی برای ورود می خواهد- در حالی که به عضو اجازه می دهد با تلفن روی همان فوب ضربه بزند تا صفحه حساب باز شود.

فرض نکنید که این دو مسیر به طور خودکار سازگار هستند زیرا تراشه NFC یکسانی دارند. آنها را جداگانه تأیید کنید:

• خواننده باید از فناوری اعتبار و شناسه دقیق استفاده شده توسط سیستم عضویت پشتیبانی کند.
• مسیر تلفن باید بار مورد تایید NDEF را خوانده و مقصد مورد انتظار را باز کند.
• پشتیبان باید بداند که چگونه خواننده-شناسه سمت خواننده و نشانه سمت NDEF- با یک حساب ارتباط دارند.
• اگر هر دو فعال باقی بمانند، یک جایگزین باید هر دو مسیر را به روز کند.

 

 

تصمیم بگیرید که کدام رکورد منبع حقیقت است

ایمن ترین طرح عضویت معمولاً حفظ می کندحساب عضوبه عنوان منبع حقیقت و با کلید به عنوان یک اعتبار قابل تخصیص رفتار می کند.

این جداسازی جایگزینی و تخصیص مجدد را آسان تر می کند.

این به اپراتور اجازه می‌دهد تا بدون بازنویسی فیزیکی فوب، یک عضو را به حالت تعلیق درآورد، بدون ایجاد حساب عضویت جدید، یک کلید کلید آسیب‌دیده را جایگزین کند، و هنگام تغییر اعتبار، سابقه تراکنش را حفظ کند.

 

قبل از اینکه دسته را رمزگذاری کنید، نقشه برداری را بسازید

تولید داده‌های متغیر{0}}را با یک ستون صفحه‌گسترده به نام «ID» شروع نکنید. ابتدا رابطه بین شناسه ها را تعریف کنید.

نقشه ساخت و استقرار ممکن است شامل موارد زیر باشد:

برای حفظ حریم خصوصی و کنترل عملیاتی، تامین کننده معمولاً نیازی به مشخصات عضو کامل ندارد. یک مدل تمیزتر جداسازی فایل نقشه برداری تولید از پایگاه داده اعضای اپراتور است.

به عنوان مثال، تامین کننده می تواند برگرداند:

سریال چاپ شده ↔ UID ↔ توکن کدگذاری شده ↔ وضعیت تولید

سپس اپراتور می تواند اضافه کند:

اعتبار ↔ شناسه عضو ↔ وضعیت عضویت

پس از صدور

 

از UID به عنوان میانبر امنیتی استفاده نکنید

UID برای شناسایی مفید است، اما شناسایی و احراز هویت عملکردهای امنیتی متفاوتی هستند.

برای جستجوی وفاداری کم{0}}خطر، نگاشت یک شناسه اعتبار پشتیبانی شده به یک حساب پشتیبان ممکن است کافی باشد. برای موارد استفاده با ریسک بالاتر مانند دسترسی به تسهیلات امن، ارزش ذخیره شده یا پرداخت، سیستم ممکن است به احراز هویت تراشه قوی‌تر، داده‌های برنامه محافظت‌شده، مدیریت کلید و امنیت جانبی خواننده- نیاز داشته باشد.

یک جا کلیدی NFC را نباید صرفاً به این دلیل امن توصیف کرد که تراشه آن دارای شماره سریال منحصر به فردی است. سطح امنیتی مورد نیاز باید از مدل تهدید مالک سیستم و مشخصات پلت فرم باشد.

به همین ترتیب، یک منطقه حافظه محافظت شده{0}}با رمز عبور مشابه احراز هویت رمزنگاری نیست.

 

برنامه گمشده-کلید-تعویض فوب قبل از راه‌اندازی

یک گردش کار جایگزین باید ضمن تغییر اعتبار فعال، حساب عضو را حفظ کند.

یک دنباله عملی این است:

1. حساب عضو را پیدا کنید.
2. اعتبار گمشده را غیرفعال علامت بزنید.
3. تأیید کنید که آیا شناسه سمت خواننده{0}} قدیمی برای استفاده در آینده مسدود شده است یا خیر.
4. جا کلیدی جایگزین را صادر کنید.
5. اعتبار جدید را به حساب عضو موجود نگاشت کنید.
6. اگر پروژه از یک توکن NDEF منحصر به فرد استفاده می کند، تصمیم بگیرید که آیا توکن قدیمی نیز باید غیرفعال یا چرخانده شود.
7. فوب جدید را در خواننده واقعی یا گردش کار تلفن تأیید کنید.
8. تأیید کنید که اعتبار قدیمی دیگر اقدام عضویت محافظت شده را کامل نمی کند.

به همین دلیل است که حساب عضو نباید به طور دائم به یک UID فیزیکی بدون لایه جایگزین مدیریتی متصل شود.

 

تخصیص مجدد عملیاتی متفاوت از تعویض است

جایگزینی همان عضو را حفظ می کند و اعتبار را تغییر می دهد. تخصیص مجدد اعتبار فیزیکی را حفظ می کند و عضو را تغییر می دهد.

این تفاوت برای کلیدهای قابل استفاده مجدد در سالن های ورزشی، باشگاه ها، برنامه های اجاره و امکانات مدیریت شده اهمیت دارد.

قبل از دادن فوب برگشتی به شخص دیگری:

• حذف رابطه عضو قدیمی؛
• تأیید کنید که حساب قدیمی هنوز نمی تواند از اعتبار استفاده کند.
• کلید فیزیکی را بازرسی کنید.
• بازخوانی شناسه الکترونیکی؛
• اگر پروژه از داده‌های خاص اعضا استفاده می‌کند، محتوای NDEF را به‌روزرسانی یا بازنویسی کنید.
• اگر پیوند قدیمی می‌توانست کپی، نشانک‌گذاری یا به اشتراک گذاشته شده باشد، یک توکن وب منحصر به فرد را بچرخانید.
• تخصیص اعتبار به عضو جدید؛
• نتیجه خواننده و/یا تلفن نهایی را تست کنید.

قوانین تخصیص مجدد باید توسط مالک سیستم تعریف شود. این واقعیت که یک فوب کلید را می توان به صورت فیزیکی دوباره استفاده کرد، ثابت نمی کند که داده های برنامه یا رابطه حساب برای استفاده مجدد آماده است.

 

از ذخیره داده های غیر ضروری اعضا بر روی صفحه کلید خودداری کنید

داده های عضویت تغییر می کند. نام ها، وضعیت طرح، امتیازات، مزایا و جزئیات تماس همگی می توانند بدون جایگزینی اعتبار فیزیکی تغییر کنند.

به همین دلیل، بسیاری از پروژه‌ها زمانی که کلید فوب تنها یک شناسه ثابت یا کد URL غیرشفاف را ذخیره می‌کند یا در معرض نمایش قرار می‌دهد، آسان‌تر است، در حالی که پشتیبان داده‌های تجاری در حال تغییر را ذخیره می‌کند.

این نیاز به بازنویسی اعتبارنامه‌ها را کاهش می‌دهد و میزان اطلاعات اعضا را که در صورت اسکن یا خواندن برچسب توسط شخصی در معرض دید قرار می‌گیرد، محدود می‌کند.

اگر یک پروژه واقعاً به داده های محافظت شده در اعتبار نیاز دارد، به جای شروع با یک محصول عمومی NTAG و تلاش برای افزودن امنیت بعدا، تراشه و معماری امنیتی را از سیستم مورد نیاز انتخاب کنید.

 

قوانین تکراری را قبل از ثبت نام تعریف کنید

دو مشکل تکراری متفاوت وجود دارد:

• شناسه های الکترونیکی یا توکن های رمزگذاری شده تکراریدر دسته تولیدی؛
• تکالیف فعال تکراریدر پایگاه داده عضویت

طرح پذیرش باید هر دو را شناسایی کند.

یک جاکلیدی که به درستی ساخته شده است همچنان می تواند برای عضو اشتباه ثبت شود. یک عضوی که به‌درستی ثبت‌نام کرده است همچنان می‌تواند دو اعتبارنامه فعال داشته باشد، در صورتی که قانون کسب‌وکار فقط یک مورد را در نظر گرفته باشد. آن ها مالکان خرابی متفاوتی هستند و باید جداگانه ثبت شوند.

 

گردش کار عضویت تمام شده را آزمایش کنید، نه فقط تشخیص NFC

یک آزمایش نمونه مفید تراکنش کامل را دنبال می کند.

برای پیشینه گسترده تر در مورد آزمایش داده های NFC، مقصدها و نقشه برداری قبل از تولید انبوه، Syntek'sچک لیست تست NFCتوضیح می دهد که چرا یک ضربه زدن موفق با گردش کار موفق یک کسب و کار یکسان نیست.

 

در RFQ Key Fob عضویت در NFC چه باید قرار داد

برای منبع مستقیم اعتبار فیزیکی، Syntek'sصفحه محصول کلید NFCمرحله بعدی تجاری است. انتخاب محصول به جای جایگزینی باید از معماری سیستم تایید شده پیروی کند.

 

قانون استقرار

برای یک برنامه عضویت یا وفاداری، با کلید NFC به عنوان یک اعتبار قابل تخصیص رفتار کنید، نه به عنوان پایگاه داده اعضا.

یک توالی استقرار قوی عبارت است از:

وظیفه عضویت ← خواننده یا مسیر تلفن ← فناوری اعتبار ← تصمیم UID/NDEF ← مدل عضو باطن ← نقشه برداری تولید ← قوانین صدور/تعویض/تخصیص مجدد ← انجام شده-آزمایش نمونه ← تایید انبوه

این توالی کلید فیزیکی، شناسه الکترونیکی، تعامل تلفنی و رکورد اعضا را تحت یک مدل داده کنترل شده نگه می دارد. همچنین جایگزین{1}}فوب گمشده و تخصیص مجدد آینده را به جای تبدیل آنها به استثناهای پایگاه داده دستی قابل مدیریت می کند.