NFC מפתחות עבור מערכות חברות: UID, NDEF ומיפוי חברים

שלט מפתח NFC יכול לזהות חבר, לפתוח חוויית אינטרנט או לעשות את שניהם. הטעות היא להתייחס לאלה כאל אותה זרימת עבודה טכנית.

בחברות או בתוכנית נאמנות, שאלת המפתח היא לא רק איזה שבב NFC לקנות. זה כןבאיזה מזהה המערכת תסמוך, היכן תתגורר רשומת החברים, וכיצד יונפק, יוחלף, יוחלף, נטרל ויוקצה מחדש שלט המפתח הפיזי מבלי לשבור את המיפוי הזה.

מדריך זה מתמקד בארכיטקטורת נתונים זו. זה מיועד למפעילי חדר כושר, מועדונים, פלטפורמות נאמנות, חברות-משלבי מערכות וצוותי רכש שמתכננים פריסת מפתח NFC בכמות גדולה.

 

התחל עם עסקת החברות, לא בשלט המפתח

שלט מפתח NFC הוא אישור. היא לא מחשבת נקודות, מחליטה אם חברות פעילה, מאחסנת את פרופיל הלקוח הסמכותי, או מיישמת כללים עסקיים בעצמה.

אינטראקציה של חברות פועלת בדרך כלל באחד משני נתיבים:

נתיב קורא-יעודי:
חבר ← NFC מפתח שלט ← קורא תואם ← מזהה אישור ← תוכנת חברות ← רשומת חבר ← צ'ק-אין / הטבה / הרשאה

נתיב הקשה בטלפון-:
חבר ← שלט מפתח NFC ← סמארטפון ← כתובת NDEF ← קצה קצה של אינטרנט או אפליקציה → רשומת חשבון או מסע פרסום → פעולת חברות

נתיבים אלה יכולים להשתמש באותו גורם צורה פיזי, אך אין להם אותן דרישות טכניות.

אם הפרויקט הוא בעיקר גישה לדלת ולא זיהוי חברות, דרישת השליטה היא מערכת הגישה המותקנת. של סינטקמדריך תאימות של מפתח קרבהמכסה את משימת המשתמש השונה הזו.

 

UID, NDEF ומזהה חבר הם שלושה דברים שונים

פרויקטי חברות נכשלים לעתים קרובות מכיוון שמספר מזהים מטופלים כאל ניתנים להחלפה.

פורום NFC מגדירNDEFכפורמט נפוץ לנתוני יישומים במכשירים ותגים תואמי NFC Forum-. רשומת NDEF יכולה לשאת URI או מטען יישום אחר, אך המשמעות העסקית של רשומה זו שייכת לאפליקציה שמאחוריה.

של NXPתיעוד NTAG213/215/216מאשרת שמשפחת NTAG21x תומכת בהתנהגות תגית NFC Forum Type 2, ISO/IEC 14443 Type A ו-NDEF מבני נתונים. הוא גם מספק UID-מתוכנת על ידי יצרן. היכולות הללו שימושיות, אך הן עדיין מייצגות שכבות שונות: UID עבור זהות שבב, NDEF עבור נתוני יישומים ורשומות אחורי עבור לוגיקה של חברות.

 

בחר אחת משלוש ארכיטקטורות חברות

1. קורא ייעודי + מיפוי אישורים

במודל זה, המפעיל מנפיק כל שלט מפתח כאישור מערכת. קורא תואם לוכד את המזהה או נתוני האפליקציה הצפויים על ידי פלטפורמת החברות. הקצה האחורי ממפה את האישור הזה לרשומת חבר.

ארכיטקטורה זו מתאימה לצ'ק-אין חוזרים-, כניסה למועדון, לוקרים, זיהוי נאמנות-בסיוע צוות ונקודות מגע מנוהלות אחרות שבהן המפעיל שולט בקורא.

השאלות הקריטיות הן:

• באיזה שבב או טכנולוגיית אישור בדיוק תומך הקורא המותקן?
• איזה ערך רושמת התוכנה: UID, מספר כרטיס, נתוני מגזר/קובץ, או מזהה-מוגדר אחר של המערכת?
• האם לחבר אחד יכול להיות יותר מאישור פעיל אחד?
• האם ניתן להשבית אישור באופן עצמאי מחשבון החבר?
• כיצד מטפלים באובדן, מוחזר או מוחלף?

NDEF עשוי להיות לא רלוונטי בארכיטקטורה זו. שלט מפתח יכול להיות אישור חברות תקף גם כאשר אין צורך בכתובת{1}}קריאה לטלפון.

2. הקש על הטלפון + כתובת NDEF

בחוויית חברות טלפונית-ראשונה, השלט בדרך כלל נושא URI NDEF שמפנה לדף אינטרנט, זרימת הפעלה, פורטל חשבון, דף נאמנות או מסלול אפליקציה.

הסקירה טכנית של פורום NFCמתאר תגיות פורום NFC כנשאים של הודעות NDEF שיכולות להפעיל פעולות כגון פתיחת קישור אינטרנט. אפל גם מתעדת קריאת תג NFC ברקע סביב רשומות NDEF URI במכשירי אייפון נתמכים בNFC ליבה.

עבור ארכיטקטורה זו, כתובת URL ייחודית צריכה בדרך כלל להכיל אסימון אטום או מזהה פרויקט במקום לחשוף את שם החבר, האימייל, היתרה או נתונים אישיים מיותרים אחרים ישירות בתג.

לאחר מכן, הקצה האחורי של האינטרנט יכול לפתור את האסימון הזה לרשומה המתאימה ולהחליט מה המשתמש רשאי לראות או לעשות.

3. קורא היברידי + אינטראקציה טלפונית

חלק מהפרויקטים רוצים שלט מפתח אחד כדי לתמוך בזרימת עבודה של קורא מנוהל ובחוויית הקשה בטלפון.-

זה יכול להיות שימושי, למשל, כאשר חדר כושר רוצה קורא ייעודי לביצוע צ'ק-אין- ובמקביל מאפשר לחבר להקיש על אותו שלט עם טלפון כדי לפתוח דף חשבון.

אל תניח ששני הנתיבים תואמים אוטומטית מכיוון שהם חולקים את אותו שבב NFC. אמת אותם בנפרד:

• על הקורא לתמוך בטכנולוגיית האישורים המדויקת ובמזהה המשמשים את מערכת החברות;
• נתיב הטלפון חייב לקרוא את מטען ה-NDEF המאושר ולפתוח את היעד הצפוי;
• הקצה העורפי חייב לדעת כיצד מזהה הצד של הקורא-ואסימון הצד של הקורא- קשורים לאותו חשבון;
• תחליף חייב לעדכן את שני הנתיבים אם שניהם נשארים פעילים.

 

 

החלט איזה רשומה הוא מקור האמת

עיצוב החברות הבטוח ביותר שומר בדרך כלל עלחשבון חברכמקור האמת ומתייחס לשלט המפתח כאל אישור שניתן להקצות.

ההפרדה הזו מקלה על ההחלפה וההקצאה מחדש.

זה מאפשר למפעיל להשעות חבר מבלי לשכתב פיזית את השלט, להחליף שלט מפתח פגום מבלי ליצור חשבון חבר חדש ולשמור על היסטוריית עסקאות כאשר האישור משתנה.

 

בנה את המיפוי לפני שאתה מקודד את האצווה

אל תתחיל בייצור-נתונים עם עמודת גיליון אלקטרוני אחת בשם "מזהה". תחילה הגדר את הקשר בין המזהים.

מפת ייצור ופריסה עשויה לכלול:

לצורך פרטיות ושליטה תפעולית, הספק בדרך כלל אינו זקוק לפרופיל החברים המלא. מודל נקי יותר הוא להפריד את קובץ מיפוי הייצור ממאגר החברים של המפעיל.

לדוגמה, הספק יכול להחזיר:

סדרתי מודפס ↔ UID ↔ אסימון מקודד ↔ מצב ייצור

לאחר מכן המפעיל יכול להוסיף:

אישור ↔ מזהה חבר ↔ סטטוס חברות

לאחר ההנפקה.

 

אל תשתמש ב-UID כקיצור דרך אבטחה

UID שימושי לזיהוי, אך זיהוי ואימות הם פונקציות אבטחה שונות.

לבדיקת נאמנות-נמוכה, מיפוי מזהה נתמך לחשבון קצה עשוי להספיק. למקרי שימוש- בסיכון גבוה יותר, כגון גישה מאובטחת למתקן, ערך מאוחסן או תשלום, המערכת עשויה לדרוש אימות שבב חזק יותר, נתוני יישומים מוגנים, ניהול מפתחות ואבטחת צד- של הקוראים.

אין לתאר שלט מפתח NFC בסיסי כמאובטח רק בגלל שלשבב שלו יש מספר סידורי ייחודי. רמת האבטחה הנדרשת חייבת להגיע ממודל האיומים ומפרט הפלטפורמה של בעל המערכת.

באופן דומה, אזור זיכרון-מוגן בסיסמה אינו זהה לאימות קריפטוגרפי.

 

תוכנית אבודה-מפתח-החלפת שלט לפני ההשקה

זרימת עבודה חלופית אמורה לשמר את חשבון החבר תוך כדי שינוי האישור הפעיל.

רצף מעשי הוא:

1. מצא את חשבון החבר.
2. סמן את האישור שאבד כבלתי פעיל.
3. אשר אם מזהה הצד הישן של הקורא- חסום לשימוש עתידי.
4. הנפק את שלט המפתח החלופי.
5. מפה את האישור החדש לחשבון החבר הקיים.
6. אם הפרויקט משתמש באסימון NDEF ייחודי, החלט אם יש להשבית או לסובב גם את האסימון הישן.
7. אמת את השלט החדש בזרימת העבודה האמיתית של הקורא או הטלפון.
8. אשר שהאישור הישן אינו משלים עוד את פעולת החברות המוגנת.

זו הסיבה שחשבון החבר לא אמור להיות קשור לצמיתות ל-UID פיזי אחד ללא שכבת החלפה מנהלתית.

 

הקצאה מחדש היא פעולה שונה מהחלפה

החלפה שומרת על אותו חבר ומשנה את האישור. הקצאה מחדש שומרת על האישור הפיזי ומשנה את החבר.

ההבדל הזה חשוב עבור שלטי מפתח לשימוש חוזר בחדרי כושר, מועדונים, תוכניות השכרה ומתקנים מנוהלים.

לפני מתן שלט שהוחזר לאדם אחר:

• להסיר את מערכת היחסים הישנה לחבר;
• אשר שהחשבון הישן אינו יכול עדיין להשתמש באישור;
• בדוק את שלט המפתח הפיזי;
• לקרוא בחזרה את המזהה האלקטרוני;
• לעדכן או להחליף תוכן NDEF אם הפרויקט משתמש בנתונים ספציפיים-לחברים;
• שקול לסובב אסימון אינטרנט ייחודי אם ניתן היה להעתיק את הקישור הישן, לסמן או לשתף אותו;
• להקצות את האישור לחבר החדש;
• בדוק את התוצאה הסופית של הקורא ו/או הטלפון.

כללי הקצאה מחדש צריכים להיות מוגדרים על ידי בעל המערכת. העובדה שניתן לעשות שימוש חוזר פיזי בשלט מפתח אינה מוכיחה שנתוני האפליקציה או קשר החשבון מוכנים לשימוש חוזר.

 

הימנע מאחסנת נתוני חברים מיותרים בשלט המפתח

שינויים בנתוני החברות. שמות, סטטוס תוכנית, נקודות, הטבות ופרטים ליצירת קשר יכולים כולם להשתנות מבלי להחליף את האישור הפיזי.

מסיבה זו, פרויקטים רבים קלים יותר לתפעול כאשר השלט מאחסן או חושף רק מזהה יציב או אסימון URL אטום, בעוד שהקצה האחורי מאחסן את הנתונים העסקיים המשתנים.

זה מפחית את הצורך בשכתוב אישורים ומגביל את כמות המידע של החברים שנחשף אם מישהו סורק או קורא את התג.

אם פרויקט באמת זקוק לנתונים מוגנים על האישור, בחר את השבב וארכיטקטורת האבטחה מדרישת המערכת במקום להתחיל עם מוצר NTAG גנרי ולנסות להוסיף אבטחה מאוחר יותר.

 

הגדר חוקים כפולים לפני ההרשמה

ישנן שתי בעיות כפולות שונות:

• כפולות של מזהים אלקטרוניים או אסימונים מקודדיםבאצווה המיוצרת;
• משכפל משימות פעילותבמאגר החברות.

תוכנית הקבלה צריכה לזהות את שניהם.

עדיין ניתן לרשום שלט מפתח שיוצר כהלכה לחבר הלא נכון. חבר שנרשם כהלכה עדיין יכול להיות בעל שני אישורים פעילים כאשר הכלל העסקי נועד רק לאחד. אלה בעלי כשלים שונים ויש לרשום אותם בנפרד.

 

בדוק את זרימת העבודה המוגמרת של חברות, לא רק זיהוי NFC

מבחן שימושי לדוגמה עוקב אחר העסקה השלמה.

לרקע רחב יותר על בדיקת נתוני NFC, יעדים ומיפוי לפני ייצור בכמות גדולה, של Syntekרשימת בדיקות NFCמסביר מדוע ברז מוצלח אינו זהה לזרימת עבודה עסקית מוצלחת.

 

מה להכניס ל-NFC שליט מפתח בקשת רשות

למקור ישיר של האישור הפיזי, של Syntekדף מוצר NFC שלט מפתחהוא הצעד הבא המסחרי. בחירת המוצר צריכה להיות בהתאם לארכיטקטורת המערכת המאושרת במקום להחליף אותה.

 

כלל הפריסה

עבור חברות או תוכנית נאמנות, התייחס למפתח NFC כאל אישור שניתן להקצות, לא כאל מסד הנתונים של החברים.

רצף פריסה חזק הוא:

משימת חברות ← קורא או נתיב טלפון ← טכנולוגיית אישורים ← החלטת UID/NDEF ← מודל חבר קצה ← מיפוי ייצור ← כללי בעיה/החלפה/הקצאה מחדש ← הסתיים-בדיקה לדוגמה → אישור בכמות גדולה

רצף זה שומר את שלט המפתח הפיזי, המזהה האלקטרוני, האינטראקציה בטלפון ורשומת החברים תחת מודל נתונים מבוקר אחד. זה גם הופך-החלפת שלט אבוד והקצאה מחדש עתידית לניהול במקום להפוך אותם לחריגים ידניים של מסד נתונים.