Захист паролем тегів NFC проти постійного блокування: що вибрати перед розгортанням

Коли NFC-тег використовується в загальнодоступному або клієнтському-розгортанні, вміст не повинен випадково залишатися редагованим. Але «заблокувати тег» може означати кілька різних речей, і вибір неправильного може створити проблему, яку неможливо буде вирішити після виробництва.

Практичне рішення полягає в тому, чи має тег залишатися доступним для запису, вимагати пароль для захищених операцій із пам’яттю чи стати постійно доступним-лише для читання. Четверте питання стоїть за межами цього вибору: якщо проект має довести, що фізичний тег є справжнім, простого захисту паролем або блокування-лише для читання недостатньо.

Цей посібник призначений для команд B2B, які готують наклейки NFC, етикетки, картки, дисплеї чи інші теги,-зчитувані телефоном, для масового розгортання. Він зосереджений на рішенні щодо розгортання, послідовності виробництва та критеріях прийняття, а не на етапах програмування-спеціальних програм.

 

Чотири різні вимоги часто називають «безпекою»

Вони не є взаємозамінними. Назавжди заблоковану URL-адресу можна скопіювати та відтворити на іншому звичайному тегу. Пароль може обмежити деякі операції з пам’яттю без шифрування публічної URL-адреси NDEF. Проект безпечної автентифікації все ще може використовувати URL-адресу NDEF, але значення безпеки залежить від криптографічного протоколу та верифікації серверної частини, а не від того факту, що тег доступний лише-для читання.

Якщо вам спочатку потрібні ширші основи NFC, SyntekПосібник з основ тегів NFCволодіє цим вступним завданням. Ця сторінка починається з того місця, де вже існує вміст тегу та робочий процес розгортання.

 

 

Що означає постійне блокування загальних тегів NTAG21x

NXP описує NTAG213, NTAG215 і NTAG216 як сумісні мікросхеми NFC Forum Type 2 Tag з обомаполе-програмована функція блокування-лише для читанняінастроюваний 32-розрядний захист паролем. Це окремі механізми.

вТехнічний паспорт NTAG213/215/216, статичні байти блокування та байти динамічного блокування контролюють, чи можна повторно записати визначені сторінки пам’яті користувача-. Коли встановлено відповідний біт блокування, захищена область стає лише для-читання. Процес-біту блокування є одно-спрямованим: запрограмований біт блокування не можна просто змінити з 1 на 0.

Ось чому постійне блокування належить до кінця процесу затвердження, а не до початку кодування.

TheДокументація Chrome Web NFCвикористовує ту саму операційну концепцію для підтримуваних тегів: створення тегу лише-для читання є постійною, односторонньою-операцією, і її не можна скасувати через звичайний робочий процес NDEF.

 

Захист паролем – це оборотний контроль, а не шифрування

NTAG21x також забезпечує настроюваний захист паролем. NXP документує команду-автентифікації пароля, початкову точку-захищеної зони та налаштування доступу, які можуть обмежувати операції запису або, залежно від конфігурації, операції читання та запису.

Це робить контроль на основі-паролю корисним, коли авторизованому оператору може знадобитися пізніше змінити захищений вміст.

Однак 32-розрядний теговий пароль не слід рекламувати як шифрування чи автентифікацію високого-захисту. Це функція-контролю доступу до операцій з пам’яттю. Якщо тег містить загальнодоступну URL-адресу, яку будь-хто має прочитати, запис із захистом пароля не робить цю URL-адресу конфіденційною.

Це також створює операційну залежність: хтось повинен володіти паролем, процедурою видачі, політикою відновлення та інструментами, які використовуються для автентифікації та оновлення тегу. Втрата цього контролю може перетворити теоретично перезаписуваний розгортання на практично непридатний для обслуговування.

 

Використовуйте життєвий цикл розгортання, щоб вибрати стратегію блокування

Загальнодоступне розгортання, яке найкраще підтримувати, часто є стабільною,-контрольованою компанією URL-адресою, записаною в тег, після чого-змінюється вміст на сервері. У цій моделі пам’ять NFC може бути доступною-лише для читання, тоді як цільову сторінку, вміст кампанії, інформацію про гарантію чи інформацію про продукт можна редагувати онлайн.

Синтеквеб-сайт посібник з тегів NFCохоплює окреме питання розгортання NFC-на основі URL-адреси. Рішення про блокування тут починається після схвалення цільової архітектури.

 

Не блокуйте назавжди місце призначення-власності постачальника без плану міграції

Постійне блокування заморожує те, що зберігається на чіпі, а не те, що відбувається в Інтернеті. Ця різниця корисна, лише якщо організація контролює пункт призначення або має надійний шлях міграції.

Перш ніж блокувати тег до URL-адреси, підтвердьте:

• кому належить домен;
• хто контролює перенаправлення;
• чи можна пізніше перенести пункт призначення на іншу платформу;
• чи містить URL-адреса-спеціальний шлях постачальника, який може зникнути;
• чи повинні унікальні маркери per-tag залишатися дійсними протягом очікуваного терміну розгортання;
• що станеться, коли кампанія, співробітник, запис про продукт або місцезнаходження припинять роботу.

Постійний тег, що вказує на одноразову URL-адресу SaaS, може стати постійним фізичним нагадуванням про тимчасове програмне рішення. Для-тегів із довгостроковим використанням керування URL-адресою слід розглядати як частину специфікації продукту.

 

 

Блокування має відповідати кодуванню та функціональному затвердженню

Відокремлюється безпечна послідовність виробництванаписання, перевіркаіблокування.

1. Заморозити правило корисного навантаження.Визначте точний тип запису NDEF, структуру URL-адреси, правило унікального-токена та будь-які змінні дані.
2. Закодуйте тег.Напишіть затверджене корисне навантаження, використовуючи вказаний виробничий процес.
3. Перечитайте його в електронному вигляді.Переконайтеся, що збережений запис відповідає вихідним даним.
4. Перевірте результат користувача.Торкніться готового тегу з репрезентативними цільовими телефонами або зчитувачами та підтвердьте, що запланована дія виконана.
5. Перевірте пункт призначення.Перевірте переспрямування, поведінку HTTPS, право власності на обліковий запис і будь-яке унікальне зіставлення.
6. Затвердити виробничий-еквівалентний зразок.Зразок повинен використовувати кінцевий чіп, вкладку, матеріал, стан поверхні та правило кодування.
7. Застосуйте затверджений стан захисту.Залиште доступним для запису, налаштуйте керування паролем або назавжди заблокуйте відповідно до специфікації проекту.
8. Перевірте стан-блокування публікації.Прочитайте вміст ще раз і переконайтеся, що передбачене обмеження на запис дійсно діє.
9. Запишіть результат.Зберігайте вимоги щодо зіставлення, перегляду зразка та-стану блокування разом із виробничим записом.

Цей порядок запобігає поширеній помилці: виявлення неправильної URL-адреси, дубліката маркера або неправильного запису NDEF лише після того, як тег уже назавжди став доступним-лише для читання.

 

 

Для унікальних URL-адрес файл зіставлення має таке ж значення, як і стан блокування

Пакет тегів NFC може містити загальну URL-адресу або кожна частина може містити окремий маркер. Унікальне кодування додає ще один режим помилки: тег NFC можна правильно заблокувати, але зіставити з неправильним фізичним об’єктом.

Для кодування за -штуку виробничий запис може потребувати таких полів, як:

Блокування не виправляє неправильне відображення. Правильна послідовність полягає в тому, щоб спочатку перевірити відображення, а потім застосувати необоротний стан.

 

Що перевіряти після постійного читання-тегу

Остаточна перевірка має підтвердити як те, що вміст все ще працює, так і наявність затвердженого стану захисту.

Для великих замовлень визначте, чи кожен закодований елемент чи статистично контрольований зразок перевіряється на кожному шарі. Цей план вибірки є угодою між покупцем і виробником; його не слід замінювати нечітким твердженням про те, що теги «перевірені».

 

Постійне блокування не вирішує фізичного втручання

Тег NFC лише для читання не можна переписати за допомогою звичайних операцій із пам’яттю, але загальнодоступний тег все одно можна видалити, перекрити, замінити або фізично пошкодити.

Для громадських інсталяцій подумайте, чи потребує проект також:

• несанкціонована-конструкція;
• періодичний фізичний огляд;
• друкований запасний QR;
• реєстр контрольованих активів/місцезнаходження;
• моніторинг серверної частини для неочікуваних місць призначення або використання маркерів;
• процедура заміни пошкоджених або відсутніх тегів.

Вимоги до фізичної безпеки залежать від середовища. Тег огляду стільниці, етикетка зовнішнього майна та печатка-автентифікації продукту не мають однакової моделі загрози.

 

Захист паролем не замінить автентифікацію

Ця відмінність має найбільше значення в проектах із боротьби-з підробкою.

Стандартний тег можна назавжди заблокувати, щоб його пам’ять не можна було редагувати, але видимі або читані дані все одно можна скопіювати в інший тег. Фіксований UID може бути корисним як ідентифікатор, але покладатися лише на ідентифікатор не еквівалентно криптографічному доказу.

Якщо бізнес-вимога полягає в «запобіганні несанкціонованому перезапису», блокування або-контроль запису на основі пароля може бути доречним. Якщо вимогою є «довести, що цей фізичний продукт є справжнім», проект повинен оцінити чіп і серверну частину, призначені для автентифікації.

Ця архітектура безпеки навмисно виходить за рамки цієї статті. Не перетворюйте недорогий-тег загальнодоступної URL-адреси на продукт для «проти-підробки», просто змінивши його стан блокування.

 

Визначте стан блокування в запиті пропозицій, а не після виробництва

Для прямого постачання тегів і міток NFC,-зчитуваних телефоном, компанія SyntekКатегорія тегів NFCє комерційним власником. Якщо проект потребує-власного кодування та перевірки,Категорія пристрою для читання та запису NFCє відповідним апаратним шляхом.

 

Перезамовлення потребують блокування-зміни стану-правила контролю

Повторний порядок не повинен успадковувати слово «те саме» без визначення того, що має залишатися незмінним.

Перевірку слід розглянути, якщо зміна впливає на:

• модель чіпа або поведінка пам'яті/захисту;
• тип запису NDEF або структура URL;
• загальне проти унікального кодування;
• налаштування пароля або область захисту;
• політика постійного блокування;
• друковане серійне або QR-картування;
• інкрустація, антена або готовий матеріал;
• монтажну поверхню або призначений телефон/зчитувач.

Косметична зміна ілюстрації може не вимагати повного технічного повторного тестування, але зміна, яка може змінити поведінку радіочастот, інтерпретацію даних, відображення або захист від запису, повинна ініціювати перегляд ураженого шару.

 

Правило прийняття рішень

Виберіть стан захисту з моделі обслуговування, а не зі слова «безпечний».

Зберігайте тег доступним для записупоки розгортання ще знаходиться в експлуатації.Використовуйте-контрольований паролем доступколи авторизовані майбутні оновлення пам’яті є справжньою робочою вимогою, а вибраний чіп підтримує необхідну поведінку.Використовуйте постійне блокування-лише для читанняколи закодоване корисне навантаження є остаточним і його не слід переписувати.Використовуйте криптографічну автентифікаціюколи компанія повинна перевіряти автентичність, а не просто запобігати звичайним редагуванням.

Для масового виробництва найбезпечніша послідовність:

визначити корисне навантаження → кодувати → перечитати → тестувати призначення → перевірити відображення → затвердити готовий зразок → застосувати захист → перевірити захист → випустити партію

Ця послідовність запобігає тому, щоб незворотне блокування стало незворотною помилкою виробництва.