Разработка NFC-чипа с привязкой к NFT для верификации товаров

Разрабатываем NFC-решения, обеспечивающие криптографическую привязку физического объекта к NFT. Реальная привязка — это когда физическому объекту нельзя создать дубликат без криптографической подделки. Это достижимо только если чип умеет подписывать сообщения приватным ключом, который физически встроен и не извлекаем. Наш опыт — более 5 лет в блокчейн-разработке и более 50 phygital проектов.

Как работает криптографическая привязка NFC-чипа к NFT?

Привязка строится на асимметричной криптографии. Чип хранит приватный ключ, который невозможно прочитать извне. При сканировании чип подписывает уникальное сообщение (например, адрес кошелька и blockhash). Смарт-контракт на Ethereum верифицирует подпись и связывает физический объект с токеном. Без чипа подпись подделать нельзя.

Выбор чипа: требования к криптографии

Не каждый NFC чип подходит. NTAG213/215/216 — стандартные теги для простого считывания URL. Никакой криптографии, клонируются за 10 секунд с любым Android.

Нужен чип с asymmetric key pair и signing capability:

• NTAG 424 DNA — наиболее распространённый выбор. AES-128 на борту, SUN (Secure Unique NFC) message authentication. При каждом считывании генерирует уникальное CMAC-подписанное сообщение с rolling counter. Приватный ключ записывается при производстве и не читается извне.
• Kong Halo — ECC (secp256k1 — та же кривая, что в Ethereum), каждое считывание генерирует ECDSA подпись над keccak256(chipAddress || blockHash || counter). Совместим с EIP-191 personal_sign, верификация on-chain через ecrecover.
• Arx Research HaLo — публичный ключ чипа — детерминированный адрес Ethereum. Используется в RTFKT, Adidas Physical NFT проектах.

Для серьёзного phygital проекта выбор между NTAG 424 DNA и HaLo зависит от задачи: NTAG 424 дешевле и стандартнее, HaLo нативно совместим с Ethereum подписями и не требует кастомной верификации.

Криптографическая схема привязки

HaLo / Kong Halo схема

Каждый чип имеет встроенную ключевую пару secp256k1. Публичный ключ — chipAddress. При считывании телефоном (через Web NFC API или нативное приложение) чип подписывает challenge:

signature = ECDSA.sign( privateKey, keccak256(abi.encodePacked(chipAddress, cmdBlock, counter)) ) 

counter инкрементируется при каждом считывании — replay attack невозможен. cmdBlock содержит данные о конкретной команде.

Смарт-контракт хранит маппинг chipAddress => tokenId. Верификация ownership:

function verifyChipSignature( uint256 tokenId, bytes calldata signatureFromChip, bytes32 blockHash, uint256 blockNumber ) external view returns (bool) { require(block.number - blockNumber <= MAX_BLOCK_AGE, "Stale"); address chipAddress = chipAddressOf[tokenId]; bytes32 digest = keccak256(abi.encodePacked( chipAddress, blockHash )); address recovered = ECDSA.recover(digest, signatureFromChip); return recovered == chipAddress; } 

blockHash включается в подпись чтобы привязать скан к конкретному моменту времени — защита от сохранённых и воспроизведённых подписей.

NTAG 424 DNA схема

Чип использует AES-128 CMAC. Каждое считывание генерирует URL вида https://verify.project.xyz/?e=<encrypted_uid>&c=<cmac>. encrypted_uid — зашифрованный AES-128 UID чипа (уникален), cmac — Message Authentication Code, включает rolling counter. Верификационный сервер расшифровывает UID и проверяет CMAC с известным secret key. Counter проверяется на монотонное возрастание.

Слабость по сравнению с HaLo: AES ключ должен быть известен верификационному серверу. Компрометация сервера = возможность клонирования подписей. Для HaLo приватный ключ не знает никто.

Что такое Physical Backed Token (EIP-5791)?

EIP-5791 — стандарт именно для этого. Расширяет ERC-721 двумя функциями:

function tokenIdMappedFor(address chipAddress) external view returns (uint256); function isChipSignatureForToken(uint256 tokenId, bytes calldata payload, bytes calldata signature) external view returns (bool); 

Референсная реализация — Chiru Labs PBT. Наследуемся от PBT, переопределяем логику верификации под конкретный чип.

Передача токена через chip scan:

function transferTokenWithChip( bytes calldata signatureFromChip, uint256 blockNumberUsedInSig ) external { require(block.number - blockNumberUsedInSig <= getMaxBlockhashValidWindow(), "Expired"); bytes32 blockHash = blockhash(blockNumberUsedInSig); require(blockHash != bytes32(0), "Block too old"); bytes32 digest = keccak256(abi.encodePacked(msg.sender, blockHash)); address chipAddress = digest.recover(signatureFromChip); uint256 tokenId = _chipAddressToTokenId[chipAddress]; _transfer(ownerOf(tokenId), msg.sender, tokenId); } 

Это означает: чтобы перенести NFT на новый кошелёк, нужно физически поднести предмет к телефону и подписать транзакцию одновременно. Без физического предмета — передача невозможна. Это ключевое свойство для luxury goods и collectibles.

Процесс работы

1. Анализ требований: выбор типа чипа, определение параметров привязки (количество чипов, сеть, стандарт токена).
2. Проектирование криптографической схемы: разработка протокола подписи и верификации.
3. Разработка смарт-контракта: контракт PBT с поддержкой chip scan и transfer.
4. Разработка мобильного приложения (если требуется): Web NFC или нативное приложение.
5. Интеграция с производством: прошивка чипов, генерация ключей, маппинг chipAddress → tokenId.
6. Тестирование и аудит: ручное тестирование, fuzzing (Echidna), формальная верификация.
7. Деплой и поддержка: публикация контракта, настройка инфраструктуры верификации, документация для команды заказчика.

Что входит в работу

• Выбор и закупка чипов (NTAG 424 DNA / HaLo / Kong Halo) с проверкой поставщиков.
• Разработка смарт-контракта по стандарту EIP-5791 с поддержкой chip signature verification.
• Создание мобильного приложения для iOS и Android (Web NFC или нативное).
• Интеграция с производственной линией: скрипты прошивки, генерация ключей, маппинг.
• Документация по эксплуатации и техническая поддержка на старте.

Свяжитесь с нами для консультации по вашему проекту. Закажите разработку NFC-NFT решения и мы подготовим индивидуальное предложение.