כיצד לתכנת תגיות NFC עם סוגי שבבים שונים (NTAG, MIFARE ועוד)

 

כתיבת תג היא שלוש פעולות נפרדות, לא אחת

 

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

 

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

 

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

 

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

 

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

 

השוואה בין סוגי שבבי תג NFC לפני שתכנתם אותם

 

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

 

שְׁבָב	זיכרון משתמש	סוג פורום NFC	מצב NDEF במפעל	הגנת סיסמא/מפתח	iPhone NDEF קריאה + כתיבה
NTAG 213	144 בתים	סוג 2	פורמט- מראש	32 סיביות PWD / חבילה של 16 סיביות	כֵּן
NTAG 215	504 בתים	סוג 2	פורמט- מראש	32 סיביות PWD / חבילה של 16 סיביות	כֵּן
NTAG 216	888 בתים	סוג 2	פורמט- מראש	32 סיביות PWD / חבילה של 16 סיביות	כֵּן
MIFARE Ultralight EV1	48 או 128 בתים	סוג 2	טבלת עיצוב	32 סיביות PWD / חבילה של 16 סיביות	כֵּן
MIFARE Classic 1K	1,024 בתים בסך הכל, בערך 716 זמינים ל-NDEF לאחר ניכוי חסימת היצרן ו-16 סקטור נגררים	לא סוג של פורום NFC	ניתן לפורמט,-מבוסס מגזר	מפתחות מגזר CRYPTO-1 A/B	לֹא
MIFARE DESFire EV3	2 KB עד 8 KB, מבוסס קובץ-	סוג 4	יש ליצור אפליקציה	AES-128 / 3DES, זכויות גישה לכל קובץ	כֵּן
NTAG 424 DNA	סה"כ 416 בתים, מפוצלים למיכל קיבולת של 32 בתים, קובץ NDEF של 256 בתים וקובץ נתונים מוגן של 128 בתים	סוג 4	קבצים שהוגדרו מראש-	חמישה מפתחות AES-128, אימות הדדי של 3 מעברים	כֵּן

 

דמויות NTAG21x, התנהגות-נעילת סיביות ותאימות מסוג 2 / ISO/IEC 14443 Type A לפיגיליון נתוני מוצר NXP NTAG213/215/216. מבנה MIFARE Classic 1K לפי גיליון נתונים NXP MF1S50yyX (16 סקטורים × 4 בלוקים × 16 בתים). DESFire EV3 לכל MF3D(H)x3. פריסת זיכרון DNA NTAG 424 לכלNXP.

 

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

 

NTAG 213, 215 ו-216: ברירת המחדל והתקרה האמיתית שלה

 

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

 

 

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

 

התקרה מגיעה מהר יותר ממה שאנשים מצפים. NTAG213 נותן לך 144 בתים של זיכרון משתמש, והודעת NDEF היא לא רק כתובת האתר שלך. יש מעטפת TLV, כותרת רשומה, שדה סוג ושדה אורך לפני שתו בודד של הכתובת שלך מאוחסן. רשומת URI דוחסת קידומות נפוצות כגוןhttps://www.לתוך בית בודד, שמשחזר עשרה עד עשרים בתים, ובחלק של 144-בתים ההבדל הזה הוא הגבול בין התאמה לכשל. המקום שבו צוותים נתפסים הוא לא כתובת האתר עצמה אלא התוספות: הוסף רשומת טקסט עבור תווית הניתנת לקריאה על ידי אדם, הוסף רשומת Android Application כדי שהתג יפתח אפליקציה במקום דפדפן, ומטען נוח יהפוך לשגיאת גלישה.

 

כלל האצבע שלנו, וזה מסוג הדברים שלומדים רק על ידי קידוד של כמה מיליונים כאלה: אם כתובת האתר המיועדת כולל פרמטרי שאילתה עולה על כ-90 תווים, הפסיקו לציין NTAG213 ותעברו למעלה. ההפרש בעלות היחידה בין 213 ל-215 קטן מספיק כדי שכמעט אף פעם לא שווה את הסיכון של תכנון מחדש של תוכנית- באמצע. מסע פרסום שירצה מאוחר יותר לצרף פרמטרים של UTM או מספר סידורי לכל כתובת אתר של תג יפגע בקיר ב-213 ולא יפגע בו ב-215.

 

כדאי להבין בדיוק את הגנת הסיסמה במשפחה הזו, כי היא חלשה יותר ממה שהמילה "סיסמה" מרמזת. ערך PWD של 32 סיביות מועבר בצורה ברורה ונבדק על ידי השבב, אשר משער גישת כתיבה, ובאופן אופציונלי גישת קריאה, מדף נבחר ואילך. זה מונע מחבר סקרן בציבור לשכתב את התג שלך עם טלפון. זה לא פקד קריפטוגרפי ולעולם אין לתאר אותו ללקוח כאחד. שימו לב גם שלא כל דור תומך בזה בכלל: ל-NTAG203 הישן יותר אין מנגנון סיסמה כלשהו, ​​ותיעוד הספרייה מפורש שקריאות הגנה נגדו פשוט נכשלות (תיעוד nfcpy).

 

MIFARE Classic: ניתן לכתיבה באנדרואיד, נעדר ביעילות באייפון

 

הנה מלכודת התאימות שסיימה יותר פרויקטי NFC מכל גורם בודד אחר. כל מי ששואל איך כותבים NDEF ל-MIFARE Classic כבר פועל נגד הפורמט: MIFARE Classic הוא לא סוג תג של פורום NFC, זה כרטיס ISO/IEC 14443-3A עם סקטור קנייני ומבנה מפתח שקודם למערכת האקולוגית של NDEF, ותמיכת NDEF עליו קיימת רק באמצעות קונבנצית מיפוי עליונה.

 

 

אנדרואיד מטפל במוסכמה הזו. iOS לא. ה-Core NFC של אפל מעולם לא תמך ב-MIFARE Classic, כאשר משפחות ה-MIFARE הנתמכות של הפלטפורמה מוגבלות ל-Ultralight, Plus ו-DESFire, עמדה שמפתחים אישרו שוב ושוב בפורומים של אפל עצמה (פורומים למפתחים של אפל). מכיוון ש-iOS לא יכול לפנות ישירות לזיכרון הכרטיס, אייפון לא יכול לכתוב לו NDEF ולא יכול להציג NDEF המאוחסן בו.

 

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

 

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

 

הרשו לי להיות בוטה לגבי ההמלצה, כי "זה תלוי במקרה השימוש שלכם" היא לא תשובה שימושית כאן. אם תגי ה-NFC שלך יוקשו על ידי חברי הציבור, ציין כל דבר מלבד MIFARE Classic.

 

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

 

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

 

Ultralight, DESFire ו-NTAG 424 DNA: איפה התכנות הופך לניהול מפתח

 

MIFARE Ultralight EV1 יושב קרוב ל-NTAG21x בהתנהגות ואתה מתכנת עליו תגי NFC באותו האופן, עם תקציב זיכרון קטן יותר של 48 או 128 בתים ואותה סוג של שער סיסמאות. שום דבר חדש רעיוני לא קורה.

 

DESFire ו-NTAG 424 DNA הם דיסציפלינה שונה. בחלקים מסוג 4 אלה אינך כותב בתים למפת זיכרון שטוחה, אתה פועל על מערכת קבצים עם זכויות גישה לכל-קובץ, וכל פעולה משמעותית מחייבת אימות עם מפתח AES-128 תחילה. NTAG 424 DNA נושא חמישה מפתחות AES המוגדרים על ידי הלקוח, משתמש באימות הדדי של 3 מעברים עבור קובץ הנתונים המוגן, ונושא אישור Common Criteria EAL4 הן בחומרה והן בתוכנה. צוותים שמתכנתים תגי NFC לאימות מוצר ולא להפניה פשוטה בדרך כלל מחפשים את החלק הזה במיוחד, בגלל תכונה אחת.

 

תכונה זו היא Secure Dynamic Messaging, הנכתבת לרוב בתור SUN. כאשר זה מופעל, כתובת ה-NDEF שהשבב מציג משתנה בכל הקשה אחת: השבב משקף את ה-UID שלו ומונה קריאה מונוטונית בכתובת האתר, מוצפן אופציונלית, ומוסיף CMAC המחושב עם מפתח שרק אתה והשבב מחזיקים. הקצה האחורי שלך יכול אז לזהות תג אמיתי מכתובת אתר מצולמת, ויכול להבחין בין הקשה מספר 4 להקשה מספר 4,000.

 

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

 

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

 

שש פעולות שאינך יכול להפוך לאחר שתכנת תגי NFC

 

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

 

מִבצָע	מה זה עושה	מדוע אי אפשר לבטל את זה	מתי צריך לקבוע את זה
עיצוב NDEF	כותב את מיכל היכולות	נוחת בזיכרון-ניתן לתכנות-פעם אחת	במפעל, לאחר אישור סוג השבב
ביטים של נעילה סטטית	נועל את 16 הדפים הראשונים בשבבים מסוג 2	סיביות נעילה מוגדרות-בלבד ולא ניתן לאפס אותן	רק לאחר ביטול התוכן הסופי
ביטים של נעילה דינמית	כסה 96 בתים של נתונים ב-NTAG213, 456 ב-NTAG215 ו-840 ב-NTAG216, בפירוט של 2 עמודים ב-NTAG213 ו-16 עמודים ב-NTAG215 וב-NTAG216, לפי גיליון הנתונים של NXP שצוטט למעלה	אותו מנגנון-יחיד, אותה קביעות	אותו שער כמו מנעולים סטטיים
מעבר לקריאה-בלבד	מגדיר את דגל הכתיבה של NDEF לצמיתות	לא קיימת פקודה הפוכה	מעולם לא לפני השלמת ניסוי שדה
מצב LRP על NTAG 424 DNA	מחליף AES לפעולה גמישה-לדליפה	מופעל על ידי SetConfiguration, ללא נתיב חזרה למצב AES	רק אם מודל איום מתועד דורש זאת
החלפת מפתח ללא נאמנות	מחליף מפתחות AES מהמפעל	לשבב אין נתיב שחזור אם המפתח החדש אבד	רק פעם אחת שמשמורת מפתח מוקצית רשמית

 

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

 

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

 

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

 

אימות השבב הוא מה שנכתב בחשבונית

 

 

אותנטיות השבבים אינה עניין פרנואידי בקטגוריה זו, היא פריט בדיקה-שגרתי שנכנס, והוא שייך לאותו שלב QC כמו כל בדיקה אחרת שאתה מפעיל לפני שאתה מתכנת תגי NFC בכמויות ייצור. משפחות NTAG, MIFARE, Ultralight ו- ICODE של NXP נושאות כל אחת חתימת מקוריות מבוססת ECC- שנכתבה בהפקת השבבים, 32 בתים על חלקי NTAG21x, שניתן לקרוא לאחור ולאמת מול המפתח הציבורי של היצרן. תג שמתנהג בצורה מושלמת עדיין יכול להיכשל בבדיקה הזו.

 

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

 

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

 

שאלת האבטחה הקלאסית של MIFARE, כתובה מחדש בכנות

 

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

 

בשנת 2024, מחקר על ה-FM11RF08S, שבב תואם MIFARE Classic ששוחרר בשנת 2020 עם אמצעי נגד שתוכננו במיוחד לעמוד בפני כל התקפות הכרטיס-הידועות בלבד, הביס את אמצעי הנגד הללו וחשף דלת אחורית של חומרה בתהליך. הדלת האחורית מאפשרת לכל צד שמודע לכך לסכן כל מפתח-מוגדר בכרטיס תוך דקות מרגע הגישה הפיזית, וזה תקף גם כאשר המפתחות חולקו באופן מלא לכל כרטיס (ארכיון ePrint של קריפטולוגיה). מפתחות דלת אחורית קשורים זוהו על פני קבוצה רחבה יותר של חלקים, כולל דורות קודמים של Fudan ומכשירי NXP ו-Infineon ספציפיים.

 

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

 

תכנות תגיות NFC בכמות גדולה: מה משתנה מעל אלף יחידות

 

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

 

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

 

הרובד השני הוא המקום שבו נוחתים רוב צוותי-הבית: אתה מתכנת תגי NFC עם כותב קורא על שולחן העבודה, מונע על ידי קובץ אצווה, בדרך כלל דרך מקודד USB במחלקה ACR12xx או uTrust. זה עובד טוב עד שהשבב משתנה. כלי האצווה הפתוח-שנמצא בשימוש נרחב בתחום זה, למשל, מכוון ל-ACR122 באופן ספציפי ומקודד רק ל-MIFARE Ultralight ו-Ultralight C, שהם חלקים מסוג 2, כך שהעברת הפרויקט לשבב מסוג 4 פירושו בנייה מחדש של הכלים במקום עריכת קובץ תצורה. אם אתה עדיין בוחר חומרה עבור הרובד הזה, שלנוטווח סופרים של קורא USB ו-NFC שולחני{{0}מכסה את דגמי הקוראים שרשתות הכלים הללו מצפות.

 

הנוהג בתעשייה עבור השכבה השלישית הוא קידוד- מראש במהלך הייצור, וזו הרמה שרוב הקונים לא יודעים על קיומו. על הקווים שלנו במפעל של 3,600 מ"ר, הקידוד יושב בין הדבקת שבבים להרכבה סופית, על ציוד שמחבר כל תג למקומו, כותב את הרשומה וקורא אותו בחזרה לפני שהתג ממשיך הלאה. כרטיס האימות הוא כל העניין. תג שנכשל בקריאה-חזרה נדחה-בשורה ולא מתגלה על ידי לקוח בשטח, והאצווה יוצאת עם קובץ מיפוי המקשר כל UID או TID לתוכן המדויק שנכתב אליו, וזה מה ש-CMS או פלטפורמת הניתוח שלך צריכה ביום הראשון. יכולת הדבקה אוטומטית על פני חמישה קווי ייצור עולה על 100,000 שבבים ליום, כך שהקידוד לא הופך למגבלה על זמן ההובלה.

 

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

 

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

 

תשע שאלות שיש לפתור לפני הפעלת הקידוד

 

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

 

#	שְׁאֵלָה	למה זה מחליט על השבב
1	האם מכשירי אייפון יקישו על התגים האלה?	מסיר את MIFARE Classic מהשיקול לחלוטין
2	מהו אורך כתובת האתר המלא, כולל פרמטרים עתידיים?	מגדיר את הרצפה ב-NTAG213, 215 או 216
3	האם מספיקה רשומה אחת, או שאתה צריך גם רשומת טקסט או אפליקציה?	רשומות נוספות צורכות את אותו תקציב זיכרון
4	האם היעד ישתנה במהלך חיי השירות של התג?	קובע אם נעילה קבילה אי פעם
5	האם האפליקציה טוענת תביעת אותנטיות למשתמשי הקצה?	דוחף אותך ל-NTAG 424 DNA או DESFire
6	מי מחזיק ומסובב את מפתחות ה-AES?	יש להקצות לפני שינוי מפתח כלשהו
7	מהו קריטריון הקבלה עבור אצווה שנמסרה?	מגדיר אם אימות קריאה-לאחור הוא חוזי
8	האם אתה צריך קובץ UID-ל-מיפוי תוכן?	יש לציין לפני הריצה, לא לבקש לאחר מכן
9	האם אימות חתימת מקוריות הוא חלק מ-QC נכנס?	קובע אם מיקור השבבים ניתן לביקורת

 

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

 

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

 

איפה זה משאיר קונה

 

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

 

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

 

שאלות נפוצות