הגנת סיסמה של תג NFC לעומת נעילה קבועה: מה לבחור לפני הפריסה

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

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

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

 

ארבע דרישות שונות נקראות לעתים קרובות "אבטחה"

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

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

 

 

מה המשמעות של נעילה קבועה בתגיות NTAG21x נפוצות

NXP מתאר את NTAG213, NTAG215 ו-NTAG216 כ-NFC Forum Type 2 Tags תואמי IC עם שניפונקציית נעילה-ניתנת לתכנות לקריאה-בלבדוהגנת סיסמה ניתנת להגדרה של 32 סיביות. אלו מנגנונים נפרדים.

ב-גיליון נתונים NTAG213/215/216, בתים של נעילה סטטית ובייטים של נעילה דינמית שולטים אם ניתן לכתוב שוב דפי זיכרון של משתמש מוגדרים.- כאשר מוגדר סיבית נעילה רלוונטית, האזור המוגן הופך לקריאה-בלבד. תהליך הנעילה-הוא חד-כיווני: לא ניתן לשנות סיביות נעילה מתוכנתת בחזרה מ-1 ל-0.

לכן נעילה קבועה שייכת בסוף תהליך אישור, לא בתחילת הקידוד.

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

 

הגנת סיסמה היא שליטה הפיכה, לא הצפנה

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

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

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

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

 

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

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

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

 

אל תנעל לצמיתות ספק-יעד בבעלות ללא תוכנית הגירה

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

לפני נעילת תג לכתובת אתר, אשר:

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

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

 

 

הנעילה צריכה להיות בהתאם לקידוד ואישור פונקציונלי

רצף ייצור בטוח מפרידכְּתִיבָה, אימותונְעִילָה.

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

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

 

 

עבור כתובות URL ייחודיות, קובץ המיפוי חשוב כמו מצב הנעילה

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

עבור קידוד-לכל חתיכה, רשומת הייצור עשויה להזדקק לשדות כגון:

נעילה לא מתקנת מיפוי גרוע. הרצף הנכון הוא לאמת תחילה את המיפוי ולאחר מכן להחיל את המצב הבלתי הפיך.

 

מה לבדוק לאחר שתג נקרא לצמיתות-בלבד

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

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

 

נעילה קבועה אינה פותרת חבלה פיזית

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

עבור התקנות ציבוריות, שקול אם הפרויקט צריך גם:

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

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

 

הגנת סיסמה אינה מהווה תחליף לאימות

ההבחנה הזו חשובה ביותר בפרויקטים נגד-זיופים.

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

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

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

 

הגדר את מצב הנעילה ב-RFQ, לא לאחר הייצור

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

 

הזמנות מחדש מצריכות מנעול-שינוי מצב-כלל בקרה

הזמנה חוזרת לא צריכה לרשת את המילה "אותו" מבלי להגדיר מה חייב להישאר זהה.

יש לשקול אימות מחדש כאשר שינוי משפיע על:

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

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

 

כלל ההחלטה

בחר את מצב ההגנה ממודל התחזוקה, לא מהמילה "מאבטח".

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

לייצור בכמויות גדולות, הרצף הבטוח ביותר הוא:

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

הרצף הזה מונע מנעילה בלתי הפיכה להפוך לטעות ייצור בלתי הפיכה.