כיצד לבחור שבב MIFARE: קלאסי מול פלוס מול DESFire מול אולטרה לייט

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

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

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

תשובה מהירה: איזה שבב MIFARE כדאי להעריך?

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

מהו שבב MIFARE?

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

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

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

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

מטריצת השוואת שבבים MIFARE

ההסבר על משפחות MIFARE העיקריות

MIFARE Classic EV1: בעיקר החלטת תאימות מדור קודם

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

MIFARE Classic EV1 זמין בגרסאות של 1 KB ו-4 KB ופועל במהירות של 13.56 מגה-הרץ עם קצב נתונים של 106 קילובייט לשנייה.

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

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

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

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

MIFARE Plus EV2: כלי הגירה, לא רק "קלאסיקה טובה יותר"

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

הערך האסטרטגי שלו הוא הגירה.

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

MIFARE Plus EV2 תומך באבטחת AES-128 ונועד לעזור לתשתיות קיימות ללא מגע לעבור לעבר ארכיטקטורה מאובטחת יותר.

זה הופך את שאלת המפתח:

האם אתה צריך לשמור על מעבר מבוקר ממערכת קיימת-מכוונת קלאסית?

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

MIFARE DESFire Light: מאובטח ופשוט יותר עבור יישום ראשי אחד

DESFire Light ממלא את החלל בין מוצרים פשוטים מאוד לשימוש מוגבל- ובין ארכיטקטורת DESFire EV3 הגמישה יותר-.

הוא מספק 640 בתים של זיכרון משתמש, אבטחת AES-128, תקשורת מסוג ISO/IEC 14443 מסוג A ומבנה קבצים מוגדר מראש.

מילת המפתח היאיישום בודד.

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

לכן זו יכולה להיות בחירה הגיונית יותר מאשר בחירה ב-DESFire EV3 פשוט כי ל-EV3 יש יותר זיכרון ותכונות.

MIFARE DESFire EV3: למערכות יישומים מרובות- מאובטחות וגמישות

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

הוא תומך בתקשורת ISO/IEC 14443 Type A, קצבי נתונים של עד 848 kbit/s, מבני קבצים גמישים וגרסאות זיכרון כולל 2 KB, 4 KB, 8 KB ו-16 KB.

NXP מפרט את הסמכת Common Criteria EAL5+ עבור המוצר. ניתן לבדוק פרטים טכניים עדכניים ב-דף המוצר הרשמי של MIFARE DESFire EV3.

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

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

MIFARE Ultralight EV1: For Simple Limited-השתמש באישורים

MIFARE Ultralight EV1 מיועד ליישומי שימוש-בנפח גבוה, מוגבל- שבהם הפשטות ועלות האישורים חשובים.

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

הוא משתמש בארכיטקטורת זיכרון פשוטה יותר מאשר DESFire ומספק הגנה מבוססת-סיסמה במקום מודל האבטחה המתקדם יותר של מוצרי Ultralight מבוססי DESFire או AES{{1}.

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

MIFARE Ultralight AES: שימוש מוגבל לא חייב להיות אבטחה נמוכה

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

MIFARE Ultralight AES מטפל בפער הזה על ידי שילוב של מיקום מוגבל-בשימוש עם אימות קריפטוגרפי AES-128.

NXP מזהה יישומים הכוללים תחבורה ציבורית, אירוח, גישה, כרטוס אירועים ונאמנות. פרטים טכניים זמינים ב-גיליון הנתונים הרשמי של MIFARE Ultralight AES.

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

MIFARE DUOX: לארכיטקטורות אבטחה מתקדמות יותר

MIFARE DUOX נמצא בקצה האבטחה-הגבוה יותר של תיק MIFARE הנוכחי.

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

NXP מפרטת גם את הסמכת Common Criteria EAL6+. פרטים נוספים זמינים ב-דף המוצר הרשמי של MIFARE DUOX.

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

השתמש במורכבות גבוהה יותר רק כאשר מודל האיום ודרישות המערכת מצדיקות זאת.

קלאסי מול פלוס מול DESFire: הדרך המהירה ביותר להבין את ההבדל

ההבחנה השימושית ביותר היא אפוא:

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

Ultralight AES לעומת DESFire Light: באיזה מהם כדאי לבחור?

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

אל תבחר ביניהם על סמך המילה "AES" בלבד. מודל היישום חשוב לא פחות מהפיצ'ר ההצפנה.

נתיב בחירה מעשי של MIFARE

1. האם אתה מחליף אישורים במערכת MIFARE Classic קיימת?
2. אם כן, תחילה קבע אם אתה צריך תאימות מדויקת מדור קודם או העברה מדורגת. תאימות מדויקת עשויה לשמור על קלאסיקה רלוונטית. שדרוג אבטחה מדורג עשוי להפוך את Plus EV2 למתאים יותר.
3. האם האישור הוא-זמן קצר או שימוש מוגבל-?
4. אם כן, הערך את Ultralight. השתמש בדרישת האבטחה כדי להחליט אם מוצר Ultralight בסיסי או Ultralight AES מתאים יותר.
5. האם אתה צריך אפליקציה מאובטחת ראשית אחת?
6. אם כן, הערך את DESFire Light לפני שתעבור אוטומטית למוצר רב יותר-של יישומים.
7. האם אתה צריך מספר אפליקציות, קבצים גמישים או הרחבה עתידית?
8. אם כן, DESFire EV3 הופך למועמד חזק יותר.
9. האם המערכת דורשת יכולות אבטחה-מבוססות, אסימטריות או גבוהות במיוחד-?
10. אם כן, הערך האם DUOX מתאים לארכיטקטורת האבטחה הרחבה יותר.

כיצד לבחור את שבב MIFARE המתאים שלב אחר שלב

שלב 1: הגדר מה האישור עושה בפועל

אל תתחיל עם קטלוג שבבים. רשום תחילה את פעולת המשתמש.

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

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

שלב 2: הגדר את דרישת האבטחה כאיום

"אנחנו צריכים כרטיס מאובטח" אינה דרישה מלאה.

במקום זאת, שאל מה אתה מנסה למנוע:

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

זה יוצר מיד דיון{0}}שימושי יותר בבחירת שבב.

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

שלב 3: בדוק את תאימות הקורא לפני שאתה מזמין כרטיסים

זהו אחד משלבי הרכש החשובים ביותר.

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

אם כבר יש לך מערכת מותקנת, אסוף:

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

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

מה לא מספיק כדי לאשר תאימות?

התיאורים הבאים לבדם אינם מספיקים:

• "קורא 13.56 מגה-הרץ"
• "תואם NFC"
• צילום של הכרטיס הקיים
• מידות הכרטיס הפיזי
• הצהרה שהקורא כבר עובד עם "MIFARE"

אתה צריך את הקורא המדויק ואת מפרט האישורים.

שלב 4: החלט אילו נתונים יש לאחסן

יותר זיכרון אינו טוב אוטומטית.

התחל עם מודל הנתונים.

דוגמה 1: UID או חיפוש מזהה

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

דוגמה 2: גישה פלוס זכאות

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

דוגמה 3: מספר שירותים עצמאיים

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

זוהי אחת הסיבות לכך שאין להעריך את DESFire רק כ"כרטיס עם יותר זיכרון".

שלב 5: החליטו אם אינטראקציה עם NFC לסמארטפון חשובה

אל תתייחס ל-"13.56 מגה-הרץ", "RFID" ו-"NFC" כמונחי רכש הניתנים להחלפה.

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

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

שלב 6: התאם את השבב לתקופת חיי האישור ולגורם הצורה

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

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

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

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

שלב 7: השווה את עלות המערכת הכוללת, לא רק את מחיר השבב

האישור הזול ביותר הוא לא תמיד מערכת העלות-הנמוכה ביותר.

עלות הפרויקט הכוללת עשויה לכלול:

• עלות אישור
• החלפת קורא
• שדרוגי קושחה
• שינויים בתוכנה
• ניהול מפתח
• התאמה אישית
• הַצפָּנָה
• אינטגרציה של מערכת
• בּוֹחֵן
• הֲגִירָה
• החלפת אישורים

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

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

לעולם אל תתייחס לגיליון נתונים כתחליף לבדיקת מערכת.

בדוק את השילוב המדויק של:

• שְׁבָב
• אַנטֶנָה
• חומר תעודה
• קוֹרֵא
• קושחה
• תוֹכנָה
• הַצפָּנָה
• מפתחות
• סביבת התקנה

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

איזה שבב MIFARE מתאים ליישומים שונים?

בקרת גישה

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

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

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

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

רכישת כרטיסים לאירועים

לקבלת קבלה פשוטה-לטווח קצר, התחל בהערכת משפחת Ultralight.

אם נדרש אימות חזק יותר, Ultralight AES עשויה להיות אפשרות מתאימה יותר לשימוש מוגבל-.

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

לאחר מכן ניתן לשלב את ה-IC במוצרים כגוןצמידי RFID לאירועים.

כרטיסי מפתח למלון

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

אל תבחר אישור למלון משולחן שבבים גנרי בלבד.

ראשית השג:

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

רק לאחר מכן עליך לבחור את מבנה הכרטיס, כגוןכרטיס מפתח למלון RFID.

תחבורה ציבורית

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

כרטיסים לשימוש מוגבל- עשויים להתאים למשפחת ה-Ultralight. אישורים מאובטחים לשימוש חוזר עשויים לדרוש DESFire או ארכיטקטורה חזקה אחרת. פריסות קלאסיות קיימות עשויות להזדקק ל-Plus כחלק מהעברה מדורגת.

כרטיסי קמפוס וחברות

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

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

סגור -תשלום לולאה

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

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

כיצד לגשת להגירה קלאסית של MIFARE מדור קודם

אל תתייחס להעברה כאל סדר החלפת כרטיס פשוט-.

תחילה בנה מלאי:

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

אם קוראים מדור קודם וקוראים משודרגים חייבים לפעול במהלך אותה תקופת מעבר, MIFARE Plus EV2 ראוי לתשומת לב מיוחדת מכיוון שהעברה היא אחד ממקרי השימוש העיקריים שלו.

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

טעויות בחירה נפוצות של MIFARE

בחירת השבב הנמוך ביותר-תחילה

התחל עם היישום ודרישות המערכת. יש לקחת בחשבון את מחיר היחידה לאחר תאימות, אבטחה וארכיטקטורה.

השוואת גודל זיכרון בלבד

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

בהנחה שכל אישור 13.56 מגה-הרץ תואם

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

שימוש ב-Classic כברירת מחדל עבור מערכת חדשה

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

התעלמות לקושחה ותוכנה של Reader

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

התעלמות מניהול מפתחות

תכונה קריפטוגרפית חזקה אינה מייצרת אוטומטית מערכת מאובטחת.

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

אבטחה היא אחריות-ברמת המערכת, לא רק מפרט שבב.

הזמנת ייצור המוני לפני בדיקה

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

MIFARE או NTAG: האם אתה באמת צריך MIFARE?

לא כל פרויקט של 13.56 מגה-הרץ הוא באמת בעיית בחירת MIFARE.

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

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

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

השאלה הטובה יותר היא לא:

איזה שבב RFID הכי טוב?

זה:

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

מה עליך לשלוח לספק ה-RFID שלך לפני שאתה מבקש הצעת מחיר?

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

הכן את המידע הבא:

1. בַּקָשָׁה:גישה, כרטוס, מלון, תחבורה, נאמנות, חברות או שימוש אחר
2. יצרן ודגם קורא נוכחיים:אם המערכת כבר קיימת
3. דגם כרטיס או שבב נוכחי:במיוחד עבור פרויקטי החלפה או הגירה
4. רמת אבטחה נדרשת:כולל באילו איומים המערכת צריכה לטפל
5. דרישת נתונים:מה בעצם צריך להיות מאוחסן על האישור
6. מבנה יישום:בקשה אחת או כמה
7. דרישות הסמארטפון:האם יש צורך באינטראקציה עם NFC לנייד
8. פורמט פיזי:כרטיס, צמיד, שלט מפתח, כרטיס או אישור אחר
9. משך חיים צפוי:יום אחד, מספר חודשים או מספר שנים
10. כַּמוּת:כמות מדגם וכמות ייצור צפויה
11. התאמה אישית:הדפסה, טיפול ב-UID, קידוד או דרישות נתונים אחרות
12. בּוֹחֵן:נדרש אימות קורא ותוכנה לפני הייצור

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

רשימת סופי לבחירת MIFARE

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

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

אם אתה משדרג מערכת קיימת, התחל עם דרישות תאימות והגירה.

ואם אתה עדיין לא בטוח בין MIFARE Classic, Plus, DESFire, Ultralight או IC אחר ללא מגע, ספק לספק תחילה את דגם הקורא שלך, האישור הנוכחי, היישום ודרישת האבטחה. הפרטים האלה הרבה יותר שימושיים מאשר פשוט לבקש את "השבב הטוב ביותר של MIFARE".