다양한 칩 유형(NTAG, MIFARE 등)으로 NFC 태그를 프로그래밍하는 방법

 

태그 작성은 하나가 아닌 세 가지 개별 작업입니다.

 

사람들이 NFC 태그를 프로그래밍하고 싶다고 말할 때 일반적으로 전화 앱의 동일한 버튼에 의해 트리거되는 세 가지 별개의 사항을 설명합니다.

 

첫 번째는서식 지정. NFC 칩의 메모리는 해당 사용자 영역에 임의 바이트가 아닌 NDEF 메시지가 포함되어 있음을 알려야 합니다. 이는 기능 컨테이너로 알려진 작은 데이터 구조를 작성하여 수행됩니다. NTAG21x 부품에서는 이 작업이 이미 웨이퍼 수준에서 수행되므로 칩은 NDEF-형식으로 도착하고 NDEF만 보유할 수 있습니다. MIFARE Classic 및 일부 다른 칩에서 포맷팅은 사용자가 수행하는 작업이며 구조는 일회성-프로그래밍 가능 영역에 위치합니다. 따라서 포맷은 영구적입니다. 포맷 해제 명령도 없고 이를 제공하는 공급업체 도구도 없습니다.

 

두 번째는페이로드 작성: 하나 이상의 레코드를 포함하는 NDEF 메시지로, 대부분 URL을 가리키는 URI 레코드입니다. 이것은 모두가 사진을 찍는 부분입니다. 페이로드 쓰기는 일반적으로 반복 가능하므로 마케팅 팀은 하드웨어를 다시 주문하지 않고도 6개월 후에 캠페인 태그를 리디렉션할 수 있습니다.

 

세 번째는구성: 비밀번호 바이트, 잠금 비트, 미러 설정, 액세스 조건, 인증 키. 이 레이어는 되돌릴 수 없는 결정이 내려지는 곳이며 소비자 튜토리얼이 전혀 건드리지 않는 레이어입니다. 주변에 보안 경계가 있는 모든 항목에 대해 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 초경량 EV1	48 또는 128바이트	유형 2	포맷 가능	32비트 PWD / 16비트 팩	예
MIFARE 클래식 1K	총 1,024바이트(제조업체 블록과 16개 섹터 트레일러를 제외하면 NDEF에 약 716바이트 사용 가능)	NFC 포럼 유형이 아님	포맷 가능, 섹터 기반-	CRYPTO-1 섹터 키 A/B	아니요
MIFARE DESFire EV3	2KB~8KB, 파일-기반	유형 4	애플리케이션을 생성해야 합니다.	AES-128 / 3DES, 파일별 액세스 권한	예
NTAG 424 DNA	총 416바이트, 32바이트 기능 컨테이너, 256바이트 NDEF 파일 및 128바이트 보호 데이터 파일로 분할됨	유형 4	사전{0}}프로비저닝된 파일	AES-128 키 5개, 3단계 상호 인증	예

 

NTAG21x 수치, 잠금-비트 동작 및 유형 2/ISO/IEC 14443 유형 A 준수NXP NTAG213/215/216 제품 데이터 시트. NXP 데이터 시트 MF1S50yyX(16섹터 × 4블록 × 16바이트)에 따른 MIFARE Classic 1K 구조. MF3D(H)x3당 DESFire EV3. NTAG 424 DNA 메모리 레이아웃 당NXP.

 

두 개의 열은 소프트웨어를 선택하기 전에 대부분의 프로젝트를 결정합니다. 메모리 한도와 iPhone 열입니다. 테이블에서 알 수 없는 것은 수익률입니다. 올바르게 지정된 칩은 인코딩 단계 뒤에 검증 패스가 없으면 여전히 거부를 생성합니다. 이는 이 기사 후반부의 주제입니다.

 

NTAG 213, 215 및 216: 기본 선택과 실제 한도

 

인바운드 프로젝트 5개 중 대략 4개에 대해 이 제품군이 정답이며 NTAG 215 NFC 태그 프로그래밍 방법을 배우는 데는 전화 앱을 사용하면 약 90초가 걸립니다. 칩은 NDEF-형식으로 제공되며 모든 핸드셋에서 일관되게 작동하는 레코드 유형은 일반 URI 레코드이며 Android와 iOS 모두 SDK 작업 없이 이를 작성합니다.

 

 

이는 또한 단일 vCard 또는 URL 레코드가 전체 페이로드이고 일반적으로 칩보다 물리적 형식이 더 중요한 거의 모든 디지털 명함 프로그램의 제품군입니다. 대부분의 주문은 다음 날짜에 종료됩니다.빈 흰색 PVC NFC 카드스티커보다는 카드가 지갑에 남아 있어야 하고 인쇄가 되어야 하기 때문입니다.

 

천장은 사람들이 예상하는 것보다 빨리 도착합니다. NTAG213은 144바이트의 사용자 메모리를 제공하며 NDEF 메시지는 단순한 URL이 아닙니다. 주소의 단일 문자가 저장되기 전에 TLV 래퍼, 레코드 헤더, 유형 필드 및 길이 필드가 있습니다. URI 레코드는 다음과 같은 일반적인 접두사를 압축합니다.https://www.10~20바이트를 복구하는 단일 바이트로 변환되고 144-바이트 부분에서는 그 차이가 적합과 실패의 경계입니다. 팀이 걸리는 부분은 URL 자체가 아니라 추가 항목입니다. 사람이 읽을 수 있는 레이블에 대한 텍스트 레코드를 추가하고, 태그가 브라우저 대신 앱을 열도록 Android 애플리케이션 레코드를 추가하면 편안한 페이로드가 오버플로 오류가 됩니다.

 

우리 자신의 경험 법칙은 이러한 것 중 수백만 개를 인코딩해야만 배울 수 있는 종류의 것입니다. 쿼리 매개변수를 포함하는 의도한 URL이 약 90자를 초과하는 경우 NTAG213 지정을 중지하고 위로 이동하세요. 213과 215의 단가 차이는 중간 프로그램을 재설계할 위험이 거의 없을 정도로 작습니다.- 나중에 모든 태그 URL에 UTM 매개변수 또는 일련번호를 추가하려는 캠페인은 213에서 벽에 부딪히고 215에서는 도달하지 못할 것입니다.

 

이 제품군의 비밀번호 보호는 "비밀번호"라는 단어가 암시하는 것보다 약하기 때문에 정확하게 이해할 가치가 있습니다. 32비트 PWD 값은 선택한 페이지부터 쓰기 액세스와 선택적으로 읽기 액세스를 게이트하는 칩에 의해 일반으로 전송되고 확인됩니다. 호기심 많은 대중이 전화로 태그를 다시 작성하는 것을 중지합니다. 이는 암호화 제어가 아니며 클라이언트에게 암호화 제어로 설명되어서는 안 됩니다. 또한 모든 세대가 이를 전혀 지원하는 것은 아닙니다. 이전 NTAG203에는 비밀번호 메커니즘이 전혀 없으며 라이브러리 문서에는 이에 대한 보호 호출이 단순히 실패한다고 명시되어 있습니다(nfcpy 문서).

 

MIFARE Classic: Android에서는 쓰기 가능, iPhone에서는 사실상 없음

 

다른 단일 요소보다 더 많은 NFC 프로젝트를 종료한 호환성 함정은 다음과 같습니다. MIFARE Classic에 NDEF를 작성하는 방법을 묻는 사람은 이미 형식의 결정에 대해 작업하고 있습니다. MIFARE Classic은 NFC 포럼 태그 유형이 아니며 NDEF 생태계보다 앞서는 독점 섹터 및 키 구조를 갖춘 ISO/IEC 14443-3A 카드이며 이에 대한 NDEF 지원은 위에 계층화된 매핑 규칙을 통해서만 존재합니다.

 

 

Android는 해당 규칙을 처리합니다. iOS는 그렇지 않습니다. Apple의 Core NFC는 MIFARE Classic을 지원한 적이 없으며 플랫폼에서 지원되는 MIFARE 제품군은 Ultralight, Plus 및 DESFire로 제한되어 있습니다. 개발자는 Apple 자체 포럼에서 이 입장을 반복적으로 확인했습니다(Apple 개발자 포럼). iOS는 카드 메모리의 주소를 직접 지정할 수 없기 때문에 iPhone은 카드에 NDEF를 쓸 수 없으며 저장된 NDEF를 표시할 수도 없습니다.

 

평가 중에 이것이 위험한 이유는 MIFARE Classic 태그가 iPhone에서 죽은 것처럼 보이지 않는다는 것입니다. 카드는 ISO 14443-A UID를 제공하므로 바로가기 앱은 이를 자동화 트리거로 허용하며 백그라운드 검색은 지원되는 유형의 이전에 저장된 NDEF 레코드를 계속 시작할 수 있습니다. iPhone에서 샘플을 테스트하는 조달 책임자가 응답을 보고 승인합니다. 그들이 본 동작은 태그의 메모리 내용과 아무 관련이 없으며 프로젝트에 iPhone이 실제로 읽을 수 있는 단위별 URL이 필요한 순간 ​​전체 접근 방식이 무너집니다.

 

여기에서 벗어나는 실제 규칙: iPhone과 Android용 NFC 태그를 프로그래밍하는 방법을 비교하는 사람은 생산 칩이 있는 두 플랫폼 모두에서 승인 테스트를 실행해야 하며, Android에서만 실행해서는 안 되며, 구매 주문에 있는 것과 다른 칩 샘플에서는 실행하면 안 됩니다.

 

"사용 사례에 따라 다릅니다"는 여기서 유용한 답변이 아니기 때문에 권장 사항에 대해 솔직하게 말씀드리겠습니다. 일반인이 NFC 태그를 탭하는 경우 MIFARE Classic을 제외한 다른 항목을 지정하세요.

 

이미 클래식- 기반 액세스 시스템을 사용하고 있는 팀의 경우 결정은 태그가 아닌 하나의 변수로 축소됩니다. 이는 독자 자산의 남은 서비스 수명입니다. 독자의 수명이 2~3년 남았고 어떤 스마트폰도 자격 증명을 건드릴 수 없다면 폐쇄 루프에서 Classic을 계속 사용하는 것이 방어 가능한 요청이며 실질적인 질문은 인코딩 방법이 아닌 IC 소싱 및 UID 형식이 됩니다. 이는 우리 노트에서 다루는 것입니다.설치된 시스템에 MIFARE 1K 태그 주문. 독자가 해당 기간 내에서 교체해야 하는 경우 과도기 자격 증명에 돈을 쓰지 마십시오. 한 번에 전체 자산을 AES- 기반 부분으로 이동하고 비용을 한 번만 흡수하세요.

 

동일한 계열에는 전체 QA 주기를 견딜 수 있을 정도로 교묘한 두 번째 함정이 있습니다. 일반적인 인코딩 도구가 URL에 제목을 첨부하는 친숙한 방법으로 제공하는 스마트 포스터 래퍼를 레코드에 추가하면 레코드 유형이 변경됩니다. 이렇게 래핑된 레코드는 내부에 무엇이 중첩되어 있는지에 관계없이 iOS 백그라운드 검색에서 전혀 선택되지 않습니다. Android 테스트는 모든 기기에서 통과하고 iPhone은 아무 작업도 수행하지 않으며 진단할 오류 메시지도 어디에도 없습니다.

 

초경량, DESFire 및 NTAG 424 DNA: 프로그래밍이 핵심 관리가 되는 곳

 

MIFARE Ultralight EV1은 동작 면에서 NTAG21x에 가깝고 48 또는 128바이트의 더 작은 메모리 예산과 동일한 클래스의 비밀번호 게이트를 사용하여 동일한 방식으로 NFC 태그를 프로그래밍합니다. 개념적으로 새로운 일은 일어나지 않습니다.

 

DESFire와 NTAG 424 DNA는 다른 분야입니다. 이러한 유형 4 부분에서는 플랫 메모리 맵에 바이트를 쓰지 않고,-파일별 액세스 권한이 있는 파일 시스템에서 작동하며, 모든 의미 있는 작업에는 먼저 AES-128 키로 인증해야 합니다. NTAG 424 DNA는 5개의 고객 정의 AES 키를 전달하고, 보호된 데이터 파일에 대해 3단계 상호 인증을 사용하며, 하드웨어와 소프트웨어 모두에 대해 Common Criteria EAL4 인증을 전달합니다. 단순 리디렉션이 아닌 제품 인증을 위해 NFC 태그를 프로그래밍하는 팀에서는 주로 이 부분을 특별히 찾는데, 그 이유는 한 가지 기능 때문입니다.

 

해당 기능은 종종 SUN으로 작성되는 보안 동적 메시징입니다. 이를 활성화하면 칩은 탭할 때마다 변경 사항을 표시합니다. 칩은 UID와 단조롭게 증가하는 읽기 카운터를 URL에 미러링하고 선택적으로 암호화하며 사용자와 칩이 보유한 키로만 계산된 CMAC를 추가합니다. 그러면 백엔드는 촬영된 URL에서 실제 태그를 알 수 있고, 탭 번호 4,000에서 탭 번호 4를 알 수 있습니다.

 

올바르게 구성하는 것은 사양에 영향을 미치는 부분입니다. 미러링 규칙은 자유로운 형식이 아닙니다.{1}}PICC 데이터가 암호화되면 UID와 읽기 카운터의 미러링은 선택 사항이 아닌 필수가 되며 둘은 항상 함께 이동하며 CMAC는 NDEF 메시지 끝에 있어야 합니다. 이러한 제약 조건을 중심으로 URL 구조를 설계하십시오. 그렇지 않으면 오프셋이 해결되지 않고 백엔드가 모든 읽기를 거부합니다.

 

SUN 배포에서 가장 자주 볼 수 있는 실패는 그 어떤 것과도 관련이 없습니다. 모든 공개 참조 구현 및 데모 서버는 출고 시 기본값인 모두-0 키로 구성된 상태로 배송됩니다. 이는 데모가 즉시 작동하도록 하기 때문입니다. 이에 대해 프로토타입을 프로젝트하면 프로토타입이 작동하고 키 순환 단계가 출시 체크리스트에 포함되지 않습니다. 관련된 모든 사람이 배포가 암호화되었다고 믿는 동안 태그는 암호화된 상태로 공개됩니다. 이것이 바로 우리의 샘플 릴리스 절차가 데모에 사용된 것이 아닌 생산 단위의 주요 다양화를 확인하는 이유입니다.

 

NFC 태그를 프로그래밍한 후에는 되돌릴 수 없는 6가지 작업

 

페이로드 재작성은 저렴합니다. 이것들은 그렇지 않습니다. 아래의 각각은 태그 묶음을 고정 자산으로 전환하는 결정이며, 각각은 우리가 개인적으로 교체해야 했던 폐기 재고의 원인이 되었습니다.

 

작업	기능	취소할 수 없는 이유	언제 예약해야 하는지
NDEF 형식화	기능 컨테이너를 작성합니다.	일회성--프로그래밍 가능 메모리에 저장	공장에서 칩 종류 확인 후
정적 잠금 비트	유형 2 칩의 처음 16페이지를 잠급니다.	잠금 비트는-설정만 되며 재설정할 수 없습니다.	최종 콘텐츠가 승인된 후에만
동적 잠금 비트	위에 인용된 NXP 데이터 시트에 따라 NTAG213의 96개 데이터 바이트, NTAG215의 456개, NTAG216의 840개 데이터 바이트를 NTAG213의 2페이지, NTAG215 및 NTAG216의 16페이지 단위로 처리합니다.	동일한 세트- 메커니즘만, 동일한 영속성	정적 잠금 장치와 동일한 게이트
읽기{0}}전용 스위치	NDEF 쓰기 플래그를 영구적으로 설정합니다.	역방향 명령이 존재하지 않습니다.	현장 시험이 완료되기 전에는 한번도 없었습니다.
NTAG 424 DNA의 LRP 모드	AES를 누출-복원력 있는 작업으로 전환합니다.	AES 모드로 돌아가는 경로 없이 SetConfiguration에 의해 활성화됨	문서화된 위협 모델에서 요구하는 경우에만
에스크로 없이 키 변경	공장 AES 키를 대체합니다.	새 키를 분실한 경우 칩에는 복구 경로가 없습니다.	열쇠 보관권이 공식적으로 할당된 경우에만

 

페이지 세분성은 프로그래밍 후 NFC 태그를 잠그는 방법을 물을 때 대부분의 사람들이 놓치는 실용적인 세부 사항입니다. 잠금은 단일의 전부-또는{2}}전무 스위치가 아닙니다. NTAG215 및 NTAG216에서는 16페이지 블록을 잠글 수 있으므로 혼합 레이아웃이 가능해집니다. 즉, 공장에서 잠긴 일련 번호 영역, 마케팅 팀이 쓸 수 있는 캠페인 URL 영역이 있습니다. NTAG213에서 세분성은 두 페이지로 더 세밀하지만 훨씬 작은 맵에 걸쳐 있습니다. 경계를 결정하는 것은 디자인 작업이며 인코딩 실행 후가 아니라 인코딩 실행 전에 이루어져야 합니다.

 

구축할 가치가 있는 습관은 암호화 게이트와 잠금 게이트를 분리하는 것입니다. 우리는 고객에게 주문 시점에 잠그는 것을 권장하지 않으며, 그 이유는 기술적인 것이 아니라 전적으로 상업적인 것입니다.

 

주문 내역을 통틀어 가장 빈번하게 발생하는 배송 후 요청은-결함 클레임이 아니라 목적지 변경이며, 서비스 첫 해 내에 집중됩니다. 일반적인 트리거는 랜딩 페이지 마이그레이션이나 대행사 인계이며, 주문 시점에는 둘 다 표시되지 않습니다. 비대칭이 자체적으로 결정하기 때문에 이에 대해 조치를 취하는 데 다른 사람의 오류 통계가 필요하지 않습니다. 변경할 필요가 없는 잠금 해제된 태그에는 비용이 전혀 들지 않지만 변경이 필요한 잠긴 태그에는 전체 교체 주문과 재설치 노동 비용이 소요됩니다. NFC 태그를 먼저 프로그래밍하고 현장 시험을 실행한 후 잠급니다.

 

송장에 명시된 대로 칩을 확인하세요.

 

 

칩 진위 여부는 이 범주에서 편집증적인 문제가 아니며 정기적으로 들어오는{0}}검사 항목이며 NFC 태그를 생산 수량으로 프로그래밍하기 전에 실행하는 다른 검사와 동일한 QC 단계에 속합니다. NXP의 NTAG, MIFARE, Ultralight 및 ICODE 제품군은 각각 칩 생산 시 작성된 ECC{2}} 기반 독창성 서명(NTAG21x 부품에 32바이트)을 가지고 있으며, 이를 다시 읽고 제조업체의 공개 키와 비교하여 확인할 수 있습니다. 완벽하게 작동하는 태그라도 해당 확인에 실패할 수 있습니다.

 

이는 시장이 인정하는 것보다 더 많이 발생합니다. 일반 소매 채널을 통해 NTAG21x 태그를 구매하는 엔지니어들은 샘플이 카운터 미러링을 포함하여 지정된 대로 정확하게 작동하지만 독창성 검증 하에서 복제 실리콘으로 보고한다고 제조업체 자체 커뮤니티에 보고했으며 NXP는 이러한 부품이 IC 자체가 취약할 수 있기 때문에 지원되지 않으며 보안 사용에 부적합하다고 발표했습니다(NXP 커뮤니티).

 

운영 결과는 사람들이 생각하는 것보다 범위가 좁으며 정확하게 언급할 가치가 있습니다. 귀하의 애플리케이션이 마케팅 리디렉션인 경우 복제 칩이 귀하에게 적절하게 서비스를 제공할 것이며 귀하는 신경 쓰지 않을 수도 있습니다. 애플리케이션에 인증, 변조 증거 또는 고객에 대한 위조 방지 주장이 포함된 경우{2}}검증할 수 없는 칩이 전체 전제를 무효화하고 올바른 인코딩이 아무리 많아도 이를 보상할 수 없습니다. 리더 앱을 사용하면 샘플당 확인하는 데 몇 초가 걸리며 사후-부검이 아닌 수신 QC 절차에 속합니다. 쓰기가 완료되었지만 독자가 침묵하는 사람을 위한 관련 자료:복제된 스티커가 잘 읽히는데도 여전히 문에서 작동하지 않는 이유.

 

MIFARE 클래식 보안 질문, 솔직하게 다시 설명함

 

오늘날 MIFARE Classic을 지정하는 사람은 누구나 10년 전 플랫폼의 명성이 아니라 현재 연구 위치에서 일해야 합니다.

 

2024년에는 알려진 모든 카드 전용 공격에 저항하도록 특별히 설계된 대책을 포함하여 2020년에 출시된 MIFARE Classic 호환 칩인 FM11RF08S에 대한 연구에서 이러한 대책을 무력화하고 그 과정에서 하드웨어 백도어를 발견했습니다. 백도어를 사용하면 이를 인지한 모든 당사자가 물리적 액세스 후 몇 분 이내에 카드에 있는 모든 사용자{6}}정의 키를 손상시킬 수 있으며 이는 키가 카드별로 완전히 다양화된 경우에도 마찬가지입니다(암호학 ePrint 아카이브). 관련 백도어 키는 이전 Fudan 세대와 특정 NXP 및 Infineon 장치를 포함하여 더 광범위한 부품 세트에서 식별되었습니다.

 

잘못된 결론을 내리기 전에 주의 깊게 읽어 보십시오. 이는 MIFARE Classic을 사용하는 모든 사람이 내일 공개된다는 주장이 아니며 이를 하나로 제시하지 않습니다. 수백만 개의 클래식 자격 증명이 카드를 복제하면 공격자가 체육관 사물함에 액세스할 수 있는 낮은-환경에서 작동합니다. 이 칩 제품군과 함께 사양 문서 어디에도 "보안"이라는 문구가 표시되어서는 안 되며 호텔 객실, 사무실 액세스 또는 클래식 실리콘의 무현금 결제를 위해 NFC 태그를 프로그래밍하려는 사람은 누구나 동일한 예산 주기에 맞춰 AES{4}} 기반 부품으로의 마이그레이션 가격을 책정해야 한다는 주장이 있습니다.

 

NFC 태그 대량 프로그래밍: 수천 단위 이상에서 변경되는 사항

 

지금까지 설명한 모든 내용은 확장성이 좋지 않습니다. 전화 앱은 일괄 기록이나 확인 패스 없이 한 번에 하나의 태그를 작성하며, 나중에 어떤 URL이 어떤 물리적 장치로 갔는지 증명할 방법이 없습니다. NFC 태그를 대량으로 프로그래밍하는 방법에는 세 가지 계층이 있으며, 이들 간의 점프는 기술적인 것이 아니라 운영적인 것입니다.

 

첫 번째 계층은 대략 100개 단위로 실행 가능한 휴대폰과 앱으로, 프로토타입과 내부 파일럿에 적합합니다.

 

두 번째 계층은 대부분의 내부 팀이 배치하는 위치입니다.{0}}일반적으로 ACR12xx 또는 uTrust 클래스의 USB 인코더를 통해 배치 파일로 구동되는 데스크톱의 리더기 작가로 NFC 태그를 프로그래밍합니다. 칩이 바뀔 때까지는 잘 작동합니다. 예를 들어, 이 분야에서 널리 사용되는 오픈 소스 배치 도구는 ACR122를 구체적으로 대상으로 하고 Type 2 부분인 MIFARE Ultralight 및 Ultralight C만 인코딩하므로 해당 프로젝트를 Type 4 칩으로 이동한다는 것은 구성 파일을 편집하는 대신 도구를 다시 빌드하는 것을 의미합니다. 아직도 이 계층의 하드웨어를 선택하고 계시다면USB 및 데스크톱 NFC 리더기-작성기 제품군이러한 툴체인이 기대하는 리더 모델을 다룹니다.

 

세 번째 계층에 대한 업계 관행은 제조 과정에서 사전{0}}인코딩되는데, 이는 대부분의 구매자가 존재하는지 모르는 계층입니다. 3,600m² 규모의 공장 라인에서 인코딩은 각 태그를 위치에 인덱싱하고, 기록을 쓰고, 태그가 이동하기 전에 다시 읽는 장비에서 칩 본딩과 최종 조립 사이에 위치합니다. 검증 패스가 요점입니다. 읽기에 실패한 태그는-현장에서 고객이 발견하지 않고-라인에서 거부되며 배치는 모든 UID 또는 TID를 기록된 정확한 콘텐츠에 연결하는 매핑 파일을 남깁니다. 이는 CMS 또는 분석 플랫폼이 첫날에 필요한 것입니다. 5개 생산 라인의 자동화된 본딩 용량은 하루 100,000개 이상의 칩을 처리하므로 인코딩이 리드 타임의 제약이 되지 않습니다.

 

이 설명에서 의도적으로 생략한 것은 허용 기준입니다. 다시 읽기-검증은 통과/실패 게이트이지만 계약상 허용해야 하는 실패율은 칩 제품군, 폼 팩터 및 나중에 태그가 라미네이팅되는지 여부에 따라 다릅니다. 안티-금속 스티커와 PVC 카드는 같은 회선에서 같은 방식으로 작동하지 않습니다. 해당 숫자는 기사가 아닌 특정 빌드에 대한 견적에 속하며 새 프로그램이 시작될 때 가장 먼저 설정하는 것입니다.

 

우리가 우리 자신의 능력 경계를 그리는 부분은 부품 공급업체가 일반적으로 모호하게 하기 때문에 명확하게 언급할 가치가 있습니다. 귀하의 URL 템플릿을 사용하여 NFC 태그를-사전 프로그래밍하고, 단위별로 직렬화하고, 모든 태그를 확인하고, 매핑 파일을 제공합니다. 귀하가 제공하는 AES 키를 프로비저닝해 드립니다. 우리는 귀하의 프로덕션 키를 보관하지 않고, 귀하의 검증 백엔드를 운영하지 않으며, 공장에서 애플리케이션{4}}계층 보안 설계를 올바르게 만들 수 있다는 사실도 알려주지 않습니다. 그 부분은 귀하의 것이며 달리 주장하는 공급업체는 존재하지 않는 위험 이전을 귀하에게 판매하는 것입니다.

 

인코딩 실행 전에 해결해야 할 9가지 질문

 

샘플이 도착한 후가 아니라 구매 주문 전에 이를 실행하십시오. 각 항목은 우리가 구출하도록 요청받은 적어도 하나의 프로젝트를 종료했습니다.

 

#	질문	칩을 결정하는 이유
1	iPhone이 이 태그를 탭합니까?	MIFARE Classic을 고려 대상에서 완전히 제거합니다.
2	향후 매개변수를 포함한 전체 URL 길이는 얼마입니까?	NTAG213, 215 또는 216에 바닥을 설정합니다.
3	하나의 기록으로 충분합니까, 아니면 텍스트 기록이나 앱 기록도 필요합니까?	추가 레코드는 동일한 메모리 예산을 소비합니다.
4	태그의 서비스 수명 동안 목적지가 변경됩니까?	잠금이 허용되는지 여부를 결정합니다.
5	애플리케이션이 최종 사용자에게 진위 여부를 주장합니까?	NTAG 424 DNA 또는 DESFire로 이동합니다.
6	AES 키를 보유하고 순환하는 사람은 누구입니까?	키가 변경되기 전에 할당되어야 합니다.
7	납품된 배치에 대한 승인 기준은 무엇입니까?	다시 읽기 확인이-계약에 따른 것인지 정의합니다.
8	콘텐츠 매핑 파일에-UID가-필요합니까?	실행 전에 지정해야 하며 실행 후에는 요청하지 않습니다.
9	독창성 서명 확인은 수신 QC의 일부인가요?	칩 소싱이 감사 가능한지 여부를 결정합니다.

 

9가지 모두에 답할 수 있는 팀은 일반적으로 첫 번째 시도에서 깨끗한 생산을 실행합니다. 9개 중 6개에 답할 수 있는 팀은 일반적으로 나머지 3개를 값비싼 방식으로 발견합니다.

 

9개의 질문은 일반적인 버전입니다. 우리가 실제로 작업하는 항목에는 10번째 열이 추가됩니다. 이는 일반적이 아닌 빌드에 적합한 답변이며, 해당 열은 이 기사에서 볼 수 없는 사항(휴대폰 믹스, 리더 자산, 라미네이션 프로세스 및 직렬화가 순차적이어야 하는지 무작위인지 여부)에 따라 달라집니다. 처음 9개의 답변을 보내주시면 귀하의 사양에 따라 주석이 달린 버전을 보내드리겠습니다.

 

이것이 구매자를 떠나는 곳

 

NFC 태그를 프로그래밍하는 방법에 대한 일반적인 절차는 없으며 칩별, 플랫폼별, 볼륨별 절차만 있습니다. 메모리 한도와 iPhone 질문에 대해 먼저 칩을 선택하십시오. 형식 지정, 페이로드 및 구성을 세 개의 별도 게이트로 처리합니다. 현장 시험 전에는 절대 잠그지 마세요. 들어오는 샘플의 독창성을 확인하십시오. 1,000개 이상의 단위가 있으면 앱에 대한 생각을 멈추고 확인 및 추적성에 대해 생각하기 시작하세요.

 

사양 초안이 이미 작성되어 있는 경우 위의 칩 제약 조건을 기준으로 이를 검토하고 생산이 지속되지 않는 모든 사항에 플래그를 지정해 드립니다. 실제 리더와 핸드셋에서 테스트할 수 있도록 무료 샘플을 사용할 수 있습니다. 다음에서 시작할 수도 있습니다.NFC 태그 형식은-사전 프로그래밍하고 자체적으로 확인-합니다.칩 결정이 아직 열려 있는 경우, 또는인코딩 검토를 위해 URL 구조와 대상 볼륨을 보냅니다.이미 수정된 경우입니다.

 

자주 묻는 질문