근거리 무선 통신(NFC)은 일반적으로 몇 센티미터 이내의 근접 거리에서
두 장치 간 무선 통신을 가능하게 합니다.
NFC는 13.56 MHz에서 동작하는 근접 결합 장치의 단순 무선 상호 연결을 위한
인터페이스와 프로토콜을 정의하는 국제 표준(ISO/IEC 18092)입니다.
하드웨어 표준은 [[[NFC-STANDARDS]]]에 정의되어 있습니다.
이 문서는 NFC 기술을 기반으로 한 선택된 사용 사례를 가능하게 하는 API를 정의합니다.
이 사양의 현재 범위는 NDEF입니다.
저수준 I/O 연산(예: ISO-DEP, NFC-A/B, NFC-F)과 호스트 기반 카드 에뮬레이션(HCE)은
현재 범위 내에서 지원되지 않습니다.
구현자는 이 사양이 불안정한 것으로 간주된다는 점을 인지해야 합니다.
논의에 참여하지 않는 구현자들은 사양이 호환되지 않는 방식으로 변경되는 것을 경험할 수 있습니다.
이 사양이 결국 후보 권고(Candidate Recommendation) 단계에 도달하기 전에 구현을 고려하는 벤더는
GitHub의 저장소를 구독하고 논의에 참여해야 합니다.
이 문서는 단일 제품에 적용되는 적합성(conformance) 기준을 정의합니다:
해당 인터페이스를 구현하는 UA(사용자 에이전트).
소개
Web NFC 사용자 시나리오는 다음과 같습니다: 장치를 플라스틱 카드나 스티커와 같은
수동 전원 NFC 태그에 근접시켜 데이터를 읽거나 쓰는 것.
NFC는 자기 유도를 사용하여 작동합니다. 즉 판독기(능동적이고 전원이 공급되는 장치)가
작은 전하를 방출하여 자기장을 생성합니다.
이 자기장은 수동 장치에 전원을 공급하여 데이터를 통신하기 위한 전기적 임펄스로 변환합니다.
따라서 장치들이 범위 내에 있을 때 항상 읽기가 수행됩니다(NFC 아날로그 사양 및 NFC 디지털 프로토콜, NFC Forum, 2006 참조).
P2P(peer-to-peer) 연결도 유사하게 작동하며, 장치는 주기적으로 소위 이니시에이터 모드로 전환하여
대상을 스캔한 다음 대상 모드로 되돌아갑니다. 대상이 발견되면 데이터는 태그의 경우와 동일한 방식으로 읽힙니다.
NFC는 기존 RFID 표준을 기반으로 하므로 많은 NFC 칩셋이 RFID 태그 읽기를 지원하지만,
일부는 단일 벤더에 의해서만 지원되며 NFC 표준의 일부가 아닐 수 있습니다. 따라서 이 문서는
NFC 데이터 교환 형식(NDEF)과 상호작용하는 방법을 명시합니다.
용어 및 관습
사용된 증강 백우스-나우르 형식(ABNF) 표기법은 [[RFC5234]]에 명시되어 있습니다.
NFC는 Near Field Communications의 약자로, 13.56 MHz에서 동작하는 근거리 무선 기술을 의미하며
10 cm 미만 거리에서 장치 간 통신을 가능하게 합니다. NFC 통신 프로토콜과
데이터 교환 형식은 ISO/IEC 14443 및 FeliCa를 포함한 기존 무선 주파수 식별(RFID) 표준을 기반으로 합니다.
NFC 표준에는 ISO/IEC 18092[5] 및 NFC Forum이 정의한 표준이 포함됩니다.
전체 목록은
NFC Forum 기술 사양을 참조하십시오.
NFC adapter는 주어진 하드웨어 요소(NFC 칩)에 구현된 NFC 기능에 대한 접근을 제공하는
기본 플랫폼의 소프트웨어 엔터티입니다. 장치는 내장형 어댑터와 USB를 통해 연결된 하나 이상의 어댑터 등
여러 개의 NFC 어댑터를 가질 수 있습니다.
NFC Forum Type 1: 이 태그는 ISO/IEC 14443-3A
(NFC-A)를 기반으로 합니다. 태그는 다시 쓸 수 있으며 읽기 전용으로
구성될 수 있습니다. 메모리 크기는 `96` 바이트에서 `2` K바이트 사이일 수 있습니다.
통신 속도는 `106` kbit/s 입니다. 다른 모든 유형과 달리, 이 태그들은 NFC 필드 내의 다중 태그 처리용
안티-콜리전 보호가 없습니다.
NFC Forum Type 2: 이 태그는
ISO/IEC 14443-3A (NFC-A)를 기반으로 합니다. 태그는 다시 쓸 수 있으며 읽기 전용으로 구성될 수 있습니다.
메모리 크기는 `48` 바이트에서 `2` K바이트 사이일 수 있습니다.
통신 속도는 `106` kbit/s 입니다。
NFC Forum Type 3: 이 태그는 일본 산업 표준(JIS) X 6319-4 (ISO/IEC 18092),
일반적으로 FeliCa로 알려진 것을 기반으로 합니다. 태그는 사전 구성되어 재기록 가능하거나 읽기 전용일 수 있습니다.
메모리는 `2` k바이트입니다. 통신 속도는 `212` kbit/s 또는 `424` kbit/s 입니다。
NFC Forum Type 4: 이 태그는 ISO/IEC 14443-4 A/B
(NFC A, NFC B)를 기반으로 하므로 통신을 위해 NFC-A 또는 NFC-B를 지원합니다.
또한 태그는 선택적으로 ISO-DEP(ISO/IEC 14443에 정의된 데이터 교환 프로토콜)를 지원할 수 있습니다
(ISO/IEC 14443-4:2008 Part 4: Transmission protocol). 태그는 사전 구성되어
재기록 가능하거나 읽기 전용일 수 있습니다. 가변 메모리, 최대 `32` k바이트.
`106`, `212` 또는 `424` kbit/s의 세 가지 통신 속도를 지원합니다。
NFC Forum Type 5: 이 태그는 ISO/IEC 15693 (NFC-V)을 기반으로 하며
장거리 RFID 판독기도 접근 가능한 ISO/IEC 15693 RF 태그에서 NDEF 메시지를 읽고 쓸 수 있게 합니다.
NFC 통신은 단거리로 제한되며 ISO/IEC 18092의 능동 통신 모드를 사용할 수 있는데,
이 경우 송신 피어가 필드를 생성하여 전력 소비를 균형시키고 링크 안정성을 향상시킵니다. 가변 메모리, 최대 `64` k바이트.
통신 속도는 `26.48` kbit/s 입니다。
MIFARE Standard: 이 태그는 종종 MIFARE Classic 또는 MIFARE Mini라는 브랜드 이름으로 판매되며,
ISO/IEC 14443-3A(또는 NFC-A로도 알려짐, ISO/IEC 14443-3:2011 Part 3: Initialization and anticollision에
정의됨)를 기반으로 합니다.
태그는 다시 쓸 수 있으며 읽기 전용으로 구성될 수 있습니다. 메모리 크기는
`320`에서 `4` k바이트 사이일 수 있습니다. 통신 속도는 `106` kbit/s 입니다。
MIFARE Standard는 NFC Forum 유형이 아니며 NXP 하드웨어를 사용하는 장치에서만 읽을 수 있습니다.
따라서 MIFARE Standard 기반 태그의 읽기/쓰기 지원은 비표준적이지만,
레거시 시스템에서의 인기와 사용 때문에 이 유형이 포함되어 있습니다。
NFC Forum에서 NDEF record에 대해 표준화한 데이터 유형 외에도,
버스 카드, 출입문 개폐기 등 많은 상용 제품이 MIFARE Standard를 기반으로 할 수 있으며,
이는 동작을 위해 특정 NFC 칩(카드와 판독기 제조사가 동일한 경우)을 필요로 합니다。
NDEF 레코드 및 필드
NDEF record는 NDEF message의 일부입니다. 각 레코드는 데이터 페이로드와
관련 타입 정보를 포함하는 이진 구조입니다. 이 외에도 페이로드 크기, 데이터가
여러 레코드에 걸쳐 청크화되어 있는지 등의 데이터 구조에 관한 정보를 포함합니다。
SR field(비트 `4`, short record)는 페이로드 길이가 `255` 바이트 이하인
짧은 레코드를 나타냅니다. 일반 레코드는 페이로드 길이가 `255` 바이트를 초과하여
최대 `4` GB까지 가능할 수 있습니다. 짧은 레코드는 길이를 표시하기 위해 한 바이트만 사용하고,
일반 레코드는 길이를 표시하기 위해 `4` 바이트(`2`^`32`-1 바이트)를 사용합니다。
CF field(비트 `5`, chunk flag)는 페이로드가 여러 레코드에 걸쳐
chunked되었는지를 나타냅니다。
Web NFC는 수신된 모든 청크된 레코드를 논리적 레코드로 변환하고
전송 시 필요하면 페이로드를 투명하게 청크합니다。
ME field(비트 `6`, message end)는 이 레코드가 NDEF message의 마지막인지 여부를 나타냅니다。
MB field(비트 `7`, message begin)는 이 레코드가 NDEF message의 첫 번째인지 여부를 나타냅니다。
TYPE LENGTH field는 TYPE field의 바이트 크기를 나타내는 부호 없는 8비트 정수입니다。
TYPE field는 TNF field의 값에 의해 결정되는 구조, 인코딩 및 형식을 통해
PAYLOAD field의 타입을 설명하는 전역적으로 고유하고 관리되는 식별자입니다。
[[[!NFC-RTD]]]는 TYPE field 이름 비교를 대소문자 구분 없이 해야 한다고 요구합니다。
ID LENGTH field는 ID field의 바이트 크기를 나타내는 부호 없는 8비트 정수입니다。
ID field는 URI 참조 형태의 식별자([[RFC3986]])로서 고유하며,
절대 또는 상대일 수 있습니다(후자의 경우 애플리케이션이 기본 URI를 제공해야 합니다).
중간 및 종료 청크 레코드는 ID field를 가져서는 안 되며, 다른 레코드는 가질 수 있습니다。
PAYLOAD LENGTH field는 PAYLOAD field의 바이트 크기를 나타냅니다.
SR field가 `1`이면 그 크기는 한 바이트이고, 그렇지 않으면 4바이트로,
각각 8비트 또는 32비트 부호 없는 정수를 나타냅니다。
PAYLOAD field는 애플리케이션 바이트를 담습니다. 데이터의 내부 구조는 NDEF에 대해 불투명합니다.
이후 논의되는 특정 경우에는 이 필드가 데이터로서 NDEF message를 포함할 수도 있습니다。
NFC Forum은 [[NFC-RTD]](리소스 타입 정의 사양)에서 텍스트, URL, 미디어 등과 같은
유용한 하위 레코드 타입의 소규모 집합을 표준화했습니다. 또한 스마트 포스터(선택적 임베디드 레코드 포함: url, text, signature 및 actions)와
핸오버 레코드와 같은 보다 복잡한 상호작용을 위해 설계된 레코드 타입도 있습니다。
NFC Forum의 로컬 타입은 NFC Forum 또는 애플리케이션에 의해 정의되며,
항상 소문자 문자나 숫자로 시작합니다. 이들은 보통 포함된 레코드의 로컬 컨텍스트 내에서만 고유한 짧은 문자열입니다.
타입의 의미가 포함된 레코드의 로컬 컨텍스트 밖에서는 중요하지 않고 저장 공간이 제한된 경우에 사용됩니다.
로컬 타입이 어떻게 사용되는지에 대한 예는 Smart poster를 참조하십시오。
[=로컬 타입=]은 따라서 포함 레코드 타입의 관점에서 정의되며 네임스페이스가 필요하지 않습니다.
이런 이유로 동일한 로컬 타입 이름이 다른 레코드 타입 내에서 다른 의미와 다른 페이로드 타입으로 사용될 수 있습니다。
잘 알려진 글로벌 타입
NFC Forum의 글로벌 타입은 NFC Forum에 의해 정의되고 관리되며
보통 대문자 문자로 시작합니다.
예: 텍스트는 "`T`", URL은 "`U`", 스마트 포스터는 "`Sp`",
서명은 "`Sig`", 핸오버 캐리어는 "`Hc`", 핸오버 요청은 "`Hr`", 핸오버 선택은 "`Hs`" 등。
텍스트 레코드
텍스트 레코드는 [[NDEF-TEXT]] 사양에 정의된 [=well-known type record=]입니다.
TNF field는 `1`이고 TYPE field는 "`T`"(`0x54`)입니다.
PAYLOAD field의 첫 바이트는 상태 바이트이며 그 다음에 US-ASCII 인코딩의 [=language tag=]가 옵니다.
페이로드의 나머지 부분은 상태 바이트가 나타내는 대로 UTF-8 또는 UTF-16으로 인코딩된 실제 텍스트입니다:
비트 0~5는 [=language tag=]의 길이를 정의합니다.
비트 6은 `0`입니다.
비트 7이 `0`이면 페이로드는 UTF-8로 인코딩된 것이고, `1`이면 UTF-16으로 인코딩된 것입니다。
URI 레코드
URI 레코드는 [[NDEF-URI]]에 정의되어 있습니다.
TNF field는 `1`이고 TYPE field는 "`U`"(`0x55`)입니다.
PAYLOAD field의 첫 바이트는 URI 식별자 코드로, 약어 테이블의 인덱스이며
값들이 URI의 나머지 앞에 덧붙여집니다. 예를 들어 값 `0`은 덧붙임이 없음을 나타내고,
`1`은 "`http://www.`", `0x04`는 "`https://`" 등을 나타냅니다.
페이로드의 나머지 부분은 나머지 URI를 UTF-8 문자열로 포함합니다(첫 바이트가 `0`이면 전체 URI를 의미합니다).
URI는 [[RFC3987]]에 정의되어 있으며 실제로 URN 또는 URL이 될 수 있는 UTF-8 인코딩 IRI입니다。
스마트 포스터 레코드
Smart poster는 [[NDEF-SMARTPOSTER]]에 정의되어 있으며
NDEF message를 페이로드로 포함하는 NDEF 레코드로서 주어진 웹 컨텐츠를 설명합니다. 포함되는 레코드는 다음과 같습니다:
콘텐츠와 관련된 title record 역할을 하는 0개 이상의 Text records.
여러 개의 title record가 존재할 경우, 서로 다른 language tags를 가져야 합니다。
애플리케이션은 최종 사용자에게 표시할 하나의 title record를 선택해야 합니다。
콘텐츠와 관련된 icon record 역할을 하는 0개 이상의 MIME type records.
MIME type은 보통 "`image/jpg`", "`image/png`", "`image/gif`" 또는 "`video/mpeg`"입니다。
애플리케이션은 최종 사용자에게 표시할 하나의 icon record를 선택해야 합니다。
NDEF 표준화 당시 값 `0`("행동 수행")은 SMS 전송, 통화 또는 브라우저 실행과 같은 사용 사례를 의도했습니다.
유사하게 값 `1`("나중을 위해 저장")은 SMS를 받은편지함에 저장, URL을 북마크에 저장 또는 전화번호를 연락처에 저장 등의 사용 사례를
의도했습니다.
또한 값 `2`("편집을 위해 열기")는 스마트 포스터 콘텐츠를 편집을 위한 기본 애플리케이션으로 열도록 의도되었습니다。
구현은 여기서 정의된 동작에 대해 표준화된 동작을 구현할 필요가 없습니다.
이 API에서는 애플리케이션이 어떤 동작을 정의할지(위의 사용 사례를 포함할 수 있음)를 결정합니다.
다만 Web NFC는 값들만 제공합니다。
smart poster는 애플리케이션에 따라 처리할 수 있는 다른 레코드를 포함할 수도 있습니다。
아래 예시는 텍스트와 URL 레코드를 포함하는 스마트 포스터 레코드를 보여줍니다。
서명 레코드
NDEF Signature는 [[NDEF-SIGNATURE]]에 정의되어 있습니다。
그 TYPE field는 "`Sig`"(`0x53`, `0x69`, `0x67`)를 포함하고
PAYLOAD field는 버전, 서명 및 인증서 체인을 포함합니다。
현재 명세상에서는 이것이 지원되지 않습니다。
핸오버 레코드
NFC handover는 [[NFC-HANDOVER]]에 정의되어 있으며
Bluetooth 또는 WiFi와 같은 대체 통신 매체의 협상 및 활성화를 허용하는
해당 메시지 구조를 포함합니다。
협상된 통신 매체는 이후(별도로) 두 장치 간에 사진 전송, Bluetooth 프린터로의 인쇄 또는
텔레비전으로의 비디오 스트리밍과 같은 특정 활동을 수행하는 데 사용될 것입니다。
현재 명세상으로는 이것이 지원되지 않습니다。
MIME 타입 레코드 (TNF 2)
MIME 타입 레코드는 관련 MIME type과 함께 이진 데이터를 저장하는 레코드입니다。
주: 일부 플랫폼(예: Windows Phone)은 페이로드에 추가 데이터를 저장했지만,
이러한 레코드의 모든 페이로드 데이터는 Android와 같은 다른 플랫폼에서는 무시됩니다.
Android에서 이러한 레코드를 읽으면 Chrome에서 URL을 로드하려 시도하며,
클라이언트 애플리케이션용으로 의도된 것은 아닙니다。
외부 타입 레코드 (TNF 4)
NFC Forum의 외부 타입 레코드는
애플리케이션 지정 데이터 타입을 위한 것이며 [[[NFC-RTD]]]에 정의되어 있습니다。
외부 타입은 접두사 `"urn:nfc:ext:"` 뒤에 소유자 [=도메인=] 이름을 붙이고 `U+003A` (`:`)를 추가한 URN이며,
그 뒤에 0이 아닌 타입 이름이 옵니다. 예: `"urn:nfc:ext:w3.org:atype"`는 TYPE field에
`"w3.org:atype"`로 저장됩니다。
알 수 없는 타입 레코드 (TNF 5)
알 수 없는 레코드는 관련 MIME type 없이 불투명한 데이터를 저장하는 레코드로,
기본 MIME type로 `application/octet-stream`을 가정할 수 있습니다.
[[NFC-NDEF]] 사양은 NDEF 파서가 페이로드를 처리하지 않고 저장하거나 전달할 것을 권장합니다。
변경되지 않은 타입 레코드 (TNF 6)
변경되지 않은 레코드는 청크된 데이터 세트의 레코드 청크로,
첫 레코드를 제외한 모든 레코드에 사용됩니다。
청크된 페이로드는 여러 NDEF record에 걸쳐 분산되며 다음 규칙을 따릅니다:
쓰려면 태그를 찾아 읽어야 합니다. 이를 통해 기존 데이터나 일련번호를 확인하여 실제로 쓰고자 하는 태그인지 판단할 수 있습니다.
이런 이유로 `reading` 이벤트에서 `write()`를 호출하는 것이 권장됩니다. `makeReadOnly()`에도 동일하게 적용됩니다.
아래 예제는 공통 `reading` 핸들러와 단일 쓰기에만 사용되는 핸들러 사이의 조정을 보여줍니다.
const ndef = new NDEFReader();
let ignoreRead = false;
ndef.onreading = (event) => {
if (ignoreRead) {
return; // write pending, ignore read.
}
console.log("We read a tag, but not during pending write!");
};
function write(data) {
ignoreRead = true;
return new Promise((resolve, reject) => {
ndef.addEventListener("reading", event => {
// Check if we want to write to this tag, or reject.
ndef.write(data).then(resolve, reject).finally(() => ignoreRead = false);
}, { once: true });
});
}
await ndef.scan();
try {
await write("Hello World");
console.log("We wrote to a tag!")
} catch(err) {
console.error("Something went wrong", err);
}
타임아웃으로 쓰기 예약
쓰기 작업에 시간 제한을 설정하는 것이 유용할 때가 있습니다.
예: 사용자에게 태그를 터치하도록 요청하고 일정 시간 내에 태그가 발견되지 않으면 타임아웃시키는 경우입니다.
const ndef = new NDEFReader();
ndef.onreading = (event) => console.log("We read a tag!");
function write(data, { timeout } = {}) {
return new Promise((resolve, reject) => {
const ctlr = new AbortController();
ctlr.signal.onabort = () => reject("Time is up, bailing out!");
setTimeout(() => ctlr.abort(), timeout);
ndef.addEventListener("reading", event => {
ndef.write(data, { signal: ctlr.signal }).then(resolve, reject);
}, { once: true });
});
}
await ndef.scan();
try {
// Let's wait for 5 seconds only.
await write("Hello World", { timeout: 5_000 });
} catch(err) {
console.error("Something went wrong", err);
} finally {
console.log("We wrote to a tag!");
}
스캔 오류 처리
이 예제는 {{NDEFReader/scan}} 프라미스가 거부되고 `readingerror`가 발생했을 때의 동작을 보여줍니다.
const ndef = new NDEFReader();
ndef.scan().then(() => {
console.log("Scan started successfully.");
ndef.onreadingerror = (event) => {
console.log("Error! Cannot read data from the NFC tag. Try a different one?");
};
ndef.onreading = (event) => {
console.log("NDEF message read.");
};
}).catch(error => {
console.log(`Error! Scan failed to start: ${error}.`);
});
한 번만 태그 읽기
이 예제는 단일 태그만 읽고 폴링을 중단하여 배터리 수명을 절약하는 편의 함수를 만드는 방법을 보여줍니다.
const ndef = new NDEFReader();
await ndef.scan();
ndef.onreading = async (event) => {
const decoder = new TextDecoder();
for (const record of event.message.records) {
console.log("Record type: " + record.recordType);
console.log("MIME type: " + record.mediaType);
console.log("=== data ===\n" + decoder.decode(record.data));
}
try {
await ndef.write("Overriding data is fun!");
} catch(error) {
console.log(`Write failed :-( try again: ${error}.`);
}
};
NDEF 메시지 수신 중지
{{NDEFScanOptions/signal}}을 사용하여 3초 동안 NDEF 메시지를 읽습니다.
const ndef = new NDEFReader();
const ctrl = new AbortController();
await ndef.scan({ signal: ctrl.signal });
ndef.onreading = () => {
console.log("NDEF message read.");
};
ctrl.signal.onabort = () => {
console.log("We're done waiting for NDEF messages.");
};
// Stop listening to NDEF messages after 3s.
setTimeout(() => ctrl.abort(), 3_000);
스마트 포스터 메시지 쓰기
const ndef = new NDEFReader();
const encoder = new TextEncoder();
await ndef.write({ records: [
{
recordType: "smart-poster", // Sp
data: { records: [
{
recordType: "url", // URL record for the Sp content
data: "https://my.org/content/19911"
},
{
recordType: "text", // title record for the Sp content
data: "Funny dance"
},
{
recordType: ":t", // type record, a local type to Sp
data: encoder.encode("image/gif") // MIME type of the Sp content
},
{
recordType: ":s", // size record, a local type to Sp
data: new Uint32Array([4096]) // byte size of Sp content
},
{
recordType: ":act", // action record, a local type to Sp
// do the action, in this case open in the browser
data: new Uint8Array([0])
},
{
recordType: "mime", // icon record, a MIME type record
mediaType: "image/png",
data: await (await fetch("icon1.png")).arrayBuffer()
},
{
recordType: "mime", // another icon record
mediaType: "image/jpg",
data: await (await fetch("icon2.jpg")).arrayBuffer()
}
]}
}
]});
NDEF 메시지를 페이로드로 갖는 외부 레코드 읽기
외부 타입 레코드는 애플리케이션 정의 레코드를 만드는 데 사용할 수 있으며,
이러한 레코드는 자체 NDEF records를 포함하는 NDEF message를 페이로드로 가질 수 있습니다.
이때 애플리케이션 컨텍스트에서 사용되는 local types를 포함할 수 있습니다.
스마트 포스터 레코드 타입도 페이로드로 NDEF message를 포함한다는 점에 유의하십시오.
NDEF는 레코드의 순서를 보장하지 않으므로, 관련 데이터를 캡슐화하기 위해
페이로드로 NDEF message를 갖는 외부 타입 레코드를 사용하는 것이 유용할 수 있습니다.
다음 예제는 텍스트 레코드와 스마트 포스터에서 차용한 정의의 로컬 타입 "act"(액션)를 포함하는
NDEF message를 페이로드로 갖는 소셜 포스트용 외부 레코드를 읽는 방법을 보여줍니다.
const ndef = new NDEFReader();
await ndef.scan();
ndef.onreading = (event) => {
const externalRecord = event.message.records.find(
record => record.type == "example.com:smart-poster"
);
let action, text;
for (const record of externalRecord.toRecords()) {
if (record.recordType == "text") {
const decoder = new TextDecoder(record.encoding);
text = decoder.decode(record.data);
} else if (record.recordType == ":act") {
action = record.data.getUint8(0);
}
}
switch (action) {
case 0: // do the action
console.log(`Post "${text}" to timeline`);
break;
case 1: // save for later
console.log(`Save "${text}" as a draft`);
break;
case 2: // open for editing
console.log(`Show editable post with "${text}"`);
break;
}
};
NDEF 메시지를 페이로드로 갖는 외부 레코드 쓰기
외부 타입 레코드는 애플리케이션 정의 레코드를 생성하는 데 사용될 수 있으며,
이 레코드는 페이로드로 NDEF message를 포함할 수 있습니다.
const ndef = new NDEFReader();
ndef.makeReadOnly().then(() => {
console.log("NFC tag has been made permanently read-only.");
}).catch(error => {
console.log(`Operation failed: ${error}`);
});
const ndef = new NDEFReader();
try {
await ndef.write("Hello world");
console.log("Message written.");
await ndef.makeReadOnly();
console.log("NFC tag has been made permanently read-only after writing to it.");
} catch (error) {
console.log(`Operation failed: ${error}`);
}
id 속성은 record identifier를 나타내며,
이는 절대 또는 상대 URL입니다. 식별자의 고유성 요구는 생성자에 의해 보장되며,
본 사양 자체가 보장하지는 않습니다.
NFC NDEF 사양은 record identifier 대신 "message identifier"와 "payload identifier"라는 용어를 사용하지만,
식별자는 메시지(레코드들의 집합)가 아니라 각 레코드에 연결되며 페이로드가 없을 때도 존재할 수 있습니다.
encoding 속성은 페이로드가 텍스트 데이터인 경우에 페이로드 인코딩에 사용된
[=encoding/name|encoding name=]을 나타냅니다.
lang 속성은 페이로드가 인코딩된 경우의 [=language tag=]를 나타냅니다.
language tag는 [[BCP47]] 사양에 정의된 Language-Tag 생성 규칙과 일치하는 string입니다
(가능한 값의 권위 있는 목록은 IANA Language
Subtag Registry 참조).
즉, 언어 범위는 하나 이상의 subtags로 구성되며 U+002D HYPHEN-MINUS("-")로 구분됩니다.
예를 들어 'en-AU'는 호주에서 쓰이는 영어를 나타내고, 'fr-CA'는 캐나다에서 쓰이는 프랑스어를 나타냅니다.
[[RFC5646]] 섹션 2.2.9의 유효성 기준을 만족하고 IANA 레지스트리를 참조하지 않고도 검증할 수 있는 언어 태그는 구조적으로 유효한 것으로 간주됩니다.
[=well known type names=] 외에도 조직이 커스텀 external type name을 생성할 수 있습니다.
이는 도메인 이름과 커스텀 타입 이름을 콜론 `U+003A` (`:`)로 구분하여 이어붙인 문자열입니다.
애플리케이션은 또한 local type name을 사용할 수 있으며, 이는 반드시 소문자 문자나 숫자로 시작해야 하는 문자열로,
NFC Forum의 [=local type=]에 대한 타입을 나타냅니다. 이는 일반적으로 상위 NDEFRecord의 페이로드인 NDEFMessage 내의
레코드에서 사용됩니다(예: smart poster).
local type의 컨텍스트는 이 레코드가 속한 페이로드인 NDEFMessage의 부모 레코드이며,
local type name은 해당 컨텍스트에서 사용되는 다른 타입 이름들과 충돌하지 않아야 합니다.
Web NFC의 어떤 구현도 청크된 레코드를 단일 논리 레코드로 투명하게 노출해야 하므로,
unchanged record는 명시적으로 표현되지 않습니다.
모든 well-known type record와 external type의 이진 표현은 상대 URI(RFC 3986)로 기록되어야 하며,
네임스페이스 식별자(NID) "`nfc`"와 네임스페이스 특정 문자열(NSS) "`wkt`" 및 "`ext`" 접두사,
즉 "`urn:nfc:wkt:`" 및 "`urn:nfc:ext:`" 접두사를 생략해야 합니다.
예를 들어, "`urn:nfc:ext:company.com:a`"는 "`company.com:a`"로 저장되며,
Text record의 well-known type record인 "`urn:nfc:wkt:T`"는 "`T`"로 저장됩니다.
signal 속성은 {{NDEFReader/scan()}} 작업을
중단할 수 있도록 합니다.
Writing content
이 섹션은 타이머가 만료되기 전에 다음으로 근접 범위에 들어왔을 때
NFC tag에 NDEF message를 쓰는 방법을 설명합니다.
어느 시점이든 현재 메시지가 전송되거나 쓰기가 중단될 때까지
하나의 origin에 대해 쓰기로 설정될 수 있는
NDEF message는 최대 하나뿐입니다.
write() 메서드
NDEFReader.write 메서드는 호출될 때
write a message 알고리즘을 반드시 실행해야 합니다:
|device|와 통신 범위에 있는 NFC adapter를 사용해
|output|을 버퍼로 하여 |device|로 데이터 전송을 시작합니다.
근접 범위의 NFC tag가 비포맷 상태이고
NDEF 포맷이 가능하면, 포맷한 뒤 |output|을
버퍼로써 기록합니다.
여러 어댑터는 사용자가 순차적으로 사용하는 것이 좋습니다.
서로 다른 연결된 NFC adapter 두 개 이상에서
동시에 탭이 발생할 가능성은 매우 낮습니다.
만약 발생한다면, 사용자는 바람직하게는 한 번에 하나의 장치에 대해
성공할 때까지 탭을 반복해야 할 수 있습니다.
여기서의 오류는 작업을 반복할 필요가 있음을 나타냅니다.
그렇지 않으면 사용자가 모든 연결된 NFC adapter에서
작업이 성공했다고 생각할 수 있습니다.
전송이 실패하면, |p|를 {{"NetworkError"}}로 거부하고
이 단계들을 중단합니다.
전송이 완료되면, |p|를 이행합니다.
NDEF 메시지 생성
|source:NDEFMessageSource|, |context:string|, |recordsDepth:unsigned short|가 주어졌을 때
create NDEF message하려면, 다음 단계들을 실행합니다:
이 단계들의 결과로 UA가 생성할 NDEF message에 대한 표기를 |output|으로 둡니다.
[= list/For each =] |record:NDEFRecordInit| ∈ |source|의 records list에 대해,
다음 단계들을 실행합니다:
|record:NDEFRecordInit|, |context|, |recordsDepth|로
create NDEF record를 실행한 결과를 |ndef|로 두거나,
기반 플랫폼이 |ndef|에 동등한 값을 제공하도록 합니다.
알고리즘이 예외 |e|를 던지면, |promise|를 |e|로 거부하고 이 단계들을 중단합니다.
|output|에 |ndef|를 추가합니다.
|output|과 |context|로 check created records를 실행했을 때
|error: Error|를 던지면, |promise|를 |error|로 거부하고 이 단계들을 중단합니다.
|output|을 반환합니다.
생성된 레코드 점검
|records: NDEFRecord sequence|와 |context: string|가 주어졌을 때
check created records를 수행하려면, 다음 단계들을 실행합니다:
아이콘 레코드의 미디어 타입은 `"image/"`나 `"video/"`로 제한될 수 있지만,
[[NDEF-SMARTPOSTER]] 사양은 실제로 smart poster 내에서 다른 미디어 타입 레코드도 허용하며,
예를 들어 vCard 연락처 카드의
MIME types 같은 애플리케이션별 방식으로 처리될 수 있습니다.
NDEF 레코드 생성
|record:NDEFRecordInit|, |context:string|, |recordsDepth:unsigned short|가 주어졌을 때
create NDEF record를 수행하려면, 다음 단계들을 실행합니다:
|record|의 recordType에 따라 아래 지정된 알고리즘을
|record|, |ndef|, |context|, |recordsDepth|와 함께 호출하고 그 결과를 반환합니다.
예외 |e|가 발생하면, |promise|를 |e|로 거부하고 이 단계들을 중단합니다.
그렇지 않다면, {{TypeError}}를 [= exception/throw =] 하고
이 단계들을 중단합니다.
외부 타입 검증
[[NFC-RTD]]는 외부 타입이 발급 기관의 [=domain=] 이름, 콜론 `U+003A` (`:`),
그리고 최소 한 글자 이상의 타입 이름을 포함해야 함을 규정하며,
예로 "`w3.org:member`" 같은 형태이고 모두 ASCII 문자로 저장됩니다.
[[NFC-RTD]]는 또한 “`urn:nfc:ext:`” URN 접두사를 규정하지만,
이는 NDEF record에 저장되지 않으므로 Web NFC 애플리케이션은
external type records를 생성할 때 URN 접두사를 지정하지 않아야 합니다.
[[NFC-RTD]]는 예를 들어 NDEF messages를 읽을 때처럼 외부 타입 이름이
“`urn:nfc:ext:`” URN 접두사로 표현될 것을 요구합니다. 그러나
external type records는 TNF FIELD가 `0x04`로 설정되어
구분되므로, 타입 이름 충돌에 대한 위험은 보이지 않습니다.
또한 웹에서 URN 사용을 피하라는
W3C TAG 권고가 있습니다.
따라서 Web NFC는 NDEF messages를 읽거나 쓸 때 URN 접두사를 사용하지 않습니다.
|input:USVString|이 주어졌을 때 split external type을 수행하려면,
다음 단계들을 실행합니다:
|input|에 `U+003A` (`:`)가 없으면, 실패를 반환합니다.
|domain|을 |input|의 시작부터 첫 `U+003A` (`:`) 직전까지로 둡니다.
|type|을 첫 `U+003A` (`:`) 이후부터 |input|의 끝까지(있다면)로 둡니다.
|domain|과 |type|의 쌍을 반환합니다.
|input:USVString|이 주어졌을 때 validate external type을 수행하려면,
다음 단계들을 실행합니다:
|record:NDEFRecordInit|, |ndef|가 주어졌을 때
map text to NDEF를 수행하려면, 다음 단계들을 실행합니다:
이는 클라이언트가 특별히 [=well-known type record=]에 텍스트를 쓰고자 할 때 유용합니다.
다른 선택지로는 명시적인 텍스트 MIME type과 함께 "`mime`" 값을 사용하는 것이 있으며,
예를 들어 "`text/xml`" 또는 "`text/vcard`"를 사용할 때 더 나은 구분이 가능합니다.
|context|가 `"smart-poster"`이고 |localTypeName|이
"`s`" (`0x73`)이며, |record|의 data 타입이
{{BufferSource}}가 아니거나 바이트 길이가 4를 초과하면,
{{TypeError}}를 [= exception/throw =] 합니다.
|context|가 `"smart-poster"`이고 |localTypeName|이
"`act`" (`0x61` `0x63` `0x74`) 이며,
|record|의 data 타입이 {{BufferSource}}가 아니거나
바이트 길이가 정확히 1이 아니면, {{TypeError}}를 [= exception/throw =] 하고
이 단계들을 중단합니다.
NFC device는 blocklist의 값에 해당 기기의 historical bytes 16진수 값이 포함되어 있으면
blocklisted 됩니다. ISO 14443-4 용어로, historical bytes는
RATS(Request for Answer To Select) 응답의 하위 집합입니다.
보안 및 프라이버시
신뢰 체인
구현은 사용자가 Web NFC API의 메서드를 승인할 때 부수 효과 없이 오직 그 동작만 실행되도록 보장해야 합니다.
기본적으로 NDEF는 태그에 데이터를 쓴 뒤 영구적인 읽기 전용으로 설정할 수 있게 해주는 것
너머로 내용을 신뢰할 방법을 제공하지 않습니다. 이는 공장 설정에서도 수행될 수 있습니다.
이 API를 통해 기록된 데이터는 기존 네이티브 NFC API와 마찬가지로 자동으로 서명되거나 암호화되지 않습니다.
NDEF 메시지의 무결성과 진정성을 보호하기 위해 NFC Forum은 [[NDEF-SIGNATURE]]를 도입했습니다.
NDEF signature와 키 관리의 사용 책임은 애플리케이션에 있습니다.
NFC를 통해 교환되는 데이터의 기밀성을 신뢰하기 위해, 애플리케이션은 암호화된 NFC content를 사용할 수 있습니다.
NFC를 통해 교환되는 데이터의 무결성을 신뢰하기 위해, 애플리케이션은 공개키 기반구조(PKI)에 기반한
NDEF signature를 사용할 수 있습니다.
일반적인 MIME 타입에 대한 보안 고려 사항은 [[RFC2048]] 및 [[RFC2046]]에 논의되어 있습니다.
프라이버시 영향과 구현 고려 사항
NFC 태그는 사람이 읽을 수 없는 또 다른 데이터 교환 방식이므로 바코드나 QR 코드와의 비교가 적절합니다.
이를 공유하는 것은 예기치 못한 프라이버시 및 보안 영향이 있을 수 있습니다.
웹사이트가 QR 코드를 읽으려면 이미지(카메라)를 캡처하는 방해적 UI가 사용되며, 이 이미지의 내용(QR 코드 포함)이
웹 페이지에 제공됨을 사용자에게 명확히 하여 스캔이 수행되고 있음을 분명히 합니다.
Web NFC 스캔이 활성화되어 있지 않을 때 태그를 스캔하면 호스트 OS가 처리합니다.
따라서 NFC 태그 스캔으로 URL과 앱을 실행하는 것은 Web NFC 자체가 처리하거나 지원하지 않습니다.
또한 Web NFC 스캔은 사용자 상호작용으로 활성화되어야 하며, 웹사이트가 포커스에 없거나 장치 화면이 꺼질 때
(즉, 잠금 해제 상태가 아닐 때) 스캔은 일시 중지됩니다. 이는 우발적 스캔이 발생하지 않도록 하기 위한 조치입니다.
Web NFC는 더 나아가, 스캐닝 장치를 NFC 태그 근처에 두면 데이터가 스캔될 것임을 UX 차원에서
사용자에게 매우 명확히 알리도록 구현을 권장합니다. 기본적으로 QR 코드 스캔의 UX 흐름을 모방합니다.
이를 위한 방법은 다양합니다. 예를 들어 사운드를 재생하거나, 스캔이 발생할 수 있는 동안 지속적인 UI(예: 언제든 취소 가능한
모달 대화상자)를 표시하는 방법이 있습니다.
구현은 업로드되려는 데이터를 표시하거나, 사용자가 승인할 때까지 읽은 데이터 공유를 보류하고, 사용자에게 어떤 레코드를
공유할지 선택할 수 있는 UI를 제공할 수도 있습니다.
스캔 중 읽기 및 쓰기
사용자가 태그를 스캔하면, 그 시점에 웹 애플리케이션은 태그의 데이터를 읽을 수 있고,
읽기 전용이 아니라면 태그에 데이터를 쓸 수도 있습니다. 개인 사용(예: 메이커 커뮤니티)의 소비자 스티커는
종종 잠금 해제(읽기 + 쓰기)되어 있는 반면, 상업적 배치의 NFC는 읽기 전용인 경우가 많습니다.
과거 프로토콜인 SNEP(Simple NDEF Exchange Protocol)는 능동 장치(예: 휴대폰)가
다른 능동 장치로부터 NDEF 데이터를 수신할 수 있게 했으나, Web NFC에서는 지원되지 않으며
지원되는 네이티브 플랫폼에서도 현재 폐기(deprecate) 중입니다.
더 최신 프로토콜인 TNEP(Tag NDEF Exchange Protocol)는 스캐너 장치(예: 휴대폰)와
IOT 장치 같은 능동 전원 장치 간의 양방향 통신을 허용합니다.
이는 현재 Web NFC에서 지원되지 않으며, 또한 입력 허용에 대한 제약이 있고
IOT 장치는 수락된 레코드가 유효함을 보장해야 합니다.
태그에 프라이버시 민감 데이터가 포함되어 있는 경우, 그러한 데이터는 사이트와 공유됩니다.
다만 UX가 사용자에게 데이터 교환을 먼저 확인하도록 요구한다면 즉시 공유되지 않을 수도 있습니다.
어떤 경우에는 태그/장치에 프라이버시 민감 데이터가 포함되어 있음이 명백할 수 있습니다.
예를 들어 NFC가 장착된 콘퍼런스 배지와 명함의 경우가 그렇습니다. NFC가 장착된 혈당 측정기의 경우에도 마찬가지로,
본인 또는 가까운 가족 중 누군가가 당뇨병 환자임을 시사할 수 있습니다.
다른 경우에는 그러한 일이 발생할 수 있음이 덜 명확할 수 있으나,
사용자가 앱이나 웹사이트를 사용하여 태그에 데이터를 쓸 때, 사용자도 모르게 사용자 ID와 같은 정보를 인코딩했을 수 있으며,
그 데이터는 이후 다른 어떤 사이트에서도 읽을 수 있습니다.
개인적이고 예기치 못한 데이터는 파일(예: 워드 프로세싱 문서, PDF, 카메라 이미지)에도 저장될 수 있으며,
파일 업로드 API를 통해 업로드됩니다. Web NFC API와 관련된 완화책은 파일 업로드와 관련된 완화책보다 강력하며,
데이터가 개인을 식별할 가능성은 더 낮습니다.
스캔 중 읽기 및 쓰기
태그의 스캔은 웹사이트가 태그를 식별하는 방법을 알고, 현실 세계에서 태그의 위치를 알고 있는 경우(예: 박물관 내부에 부착)
사용자 위치를 드러낼 수도 있습니다. 또한 FeliCa NFC 태그가 주로 일본에서 사용되는 점을 근거로 추론할 수도 있지만,
Web NFC는 어떤 태그 기술이 사용되었는지 드러내지 않습니다.
이는 웹 광고 및 트래킹 모델을 현실 세계로 끌어들이지 않습니다. 사용자 행동이 필요하며 백그라운드에서
트리거될 수 없고, 적절한 UX를 통해 스캔이 활성 상태임이 명확해야 하기 때문입니다.
기존 데이터 덮어쓰기
NFC 태그에 쓰면 태그가 망가지거나 “벽돌(brick)”이 되는 것에 대한 우려도 있습니다.
NFC 태그는 여러 사용자 애플리케이션이 읽을 수 있도록 설계되었으며,
NDEF 태그는 영구적으로 읽기 전용으로 만들 수 있는 쉬운 방법을 갖도록 설계되었습니다.
심지어 공장 출하 시 그 상태로 설정될 수도 있습니다.
NDEF는 데이터를 읽고 쓰기 위한 단순 교환 형식이지, 양방향 통신을 위한 것이 아닙니다.
NFC는 더 하위 기술을 기반으로 하는 여러 통신 형식을 지원(따라서 NDEF처럼 읽기 전용으로 잠기지 않음)하지만,
이들 어느 것도 Web NFC에서는 지원되지 않습니다.
NFC 사용 시 사용자에게 알려야 할 사항
이 섹션은 사용자가 NFC를 사용할 때 인지해야 할 몇 가지 사항을 자세히 설명합니다.
구현은 관련 NFC 동작이 수행되기 전 또는 수행 시 사용자가 이러한 사실을 이해하도록 돕는 것이 권장됩니다.
읽은 데이터는 사이트와 공유됩니다
사이트가 NFC 콘텐츠를 읽을 권한을 갖는 경우, 스캔된 태그의 데이터는 파일이나 이미지를 업로드하는 것과 유사한 방식으로
사이트와 공유됩니다. 다른 모든 사이트와 마찬가지로, 이 데이터를 사이트가 적절하고 의도한 방식으로 처리하는지 신뢰할지는
사용자에게 달려 있습니다.
읽기 전용이 아닌 태그의 데이터는 사이트가 수정 및 덮어쓸 수 있습니다
매장 등의 배치된 NFC 솔루션의 태그는 실수 또는 악의적 행위로 인해 수정되지 않도록 항상 읽기 전용으로 설정되어야 합니다.
개인용 태그와 스티커는 종종 공장 출하 시 잠금 해제(쓰기 가능)되어 있으며, 사용자는 이러한 태그가 스캔으로 인해
덮어쓰이거나 수정될 수 있음을 인지해야 합니다.
고정(예: 장착)된 태그를 읽으면 읽은 위치가 노출될 수 있습니다
고정 태그는 데이터에 자신의 ID나 위치를 인코딩할 수 있으며, 이를 읽으면 태그의 물리적 위치를 아는 사이트에 해당 정보가
노출됩니다. 이는 읽기가 수행된 위치를 추정할 수 있게 합니다. 여기에 서비스에 로그인한 상태가 결합되면,
사이트에 위치 정보가 공유될 수 있습니다.
기록된 데이터는 권한이 부여된 다른 앱과 사이트에서도 읽을 수 있습니다.
태그의 모든 NDEF 데이터는 적절한 접근 권한을 가진 어떤 앱이나 웹사이트에서도 읽을 수 있으므로,
그 의도가 아니라면 데이터는 오직 허가된 주체만 읽을 수 있도록 안전한 방식으로 암호화해야 합니다.
동일한 읽기 영역에 여러 태그가 동시에 존재할 수 있습니다
NFC는 한 번에 오직 하나의 태그만 읽을 수 있지만, 여러 태그를 감지하고 그중 하나를 통신할 태그로 선택할 수 있습니다.
이 사용 사례는 지갑 안에 여러 스마트 카드(NFC 기반)가 있고 카드를 꺼내고 싶지 않은 경우 등이 있습니다.
이는 주로 외부 하드웨어가 읽는 결제 카드와 교통 카드에 유용하며, Web NFC의 사용 사례는 아닙니다.
Web NFC에서는 다음의 공격 벡터를 방지하기 위해, 여러 태그가 동시에 사용 가능한 경우에는 읽기를 허용하지 않습니다.
공격 벡터의 한 예로, 누군가 합법적인 태그 위에 악성 NFC 태그/스티커를 붙여 잘못된 앱/사이트를 로드하거나
올바른 앱/사이트에 잘못된 데이터를 주입하게 할 수 있습니다. 원래 태그의 데이터를 복제하고 수정하여
(예: 악성 앱/사이트를 로드하도록 URL을 바꾸거나, 올바른 앱/사이트에 악성 데이터를 주입하도록 데이터 변경)
이를 수행할 수 있습니다. 예: 태그가 원래는 https://example.com으로 이동시켜야 하는데,
https://exаmple.com(키릴 문자 а 사용)으로 이동하도록 수정된 경우—겉보기에는 합법적으로 보이며,
사용자는 악성 사이트에 민감한 데이터를 제공하게 될 수 있습니다.
태그에서 웹사이트를 로드하는 것은 Web NFC의 범위를 벗어나지만, 위와 같은 공격 벡터 때문에
여러 태그가 사용 가능한 경우 사용자 에이전트가 URL을 자동으로 로드하지 않도록 권장됩니다.
여러 태그가 사용 가능한 경우 읽기를 허용하지 않음으로써, Web NFC는 사이트에 잘못된/악성 데이터를 주입하는 행위에
대해 잘 방어합니다. 기존 NFC 태그를 차폐하는 것은 페라이트 차폐가 필요하여 매우 눈에 띄기 때문에 쉽지 않습니다.
금속은 자기장을 방해하여 태그가 읽히지 않게 만듭니다.
자산(Assets)
보호해야 할 자산에는 다음이 포함됩니다:
전체 NDEF message,
특히 전송 중 또는 저장 상태의 NDEF records(페이로드 및 헤더 포함).
Web NFC로 트리거된 작업에 의해 덮어쓰일 때 데이터 공개 및 데이터 수정으로부터 보호되어야 합니다.
또한 솔루션에 연결된 태그를 파괴하는 등의 서비스 거부(DoS) 공격도 포함됩니다
(예: NFC 태그로 배치된 솔루션을 악의적 행위자가 파괴).
Web NFC를 사용하여 NFC content 작성자 또는 Web NFC를 사용하는 웹사이트가
직접 또는 간접적으로 파악할 수 있는
사용자 ID나 기타 프라이버시 민감 속성.
이 데이터는 직접 사용되거나 제3자에게 유출될 수 있습니다.
예: 사용자 위치, 장치 식별자, 사용자 식별자.
Web NFC를 사용하는 웹 페이지에 노출되는 사용자 데이터.
웹 페이지는 Web NFC 이외의 수단으로 사용자 데이터를 수집할 수도 있으나,
이 데이터를 NDEF 레코드에 포함하여 Web NFC를 통해 공유할 수 있습니다.
사용자 장치의 무결성.
NFC 태그를 읽는 행위가 사용자 장치의 손상을 초래할 수 있으며,
이는 다른 Web NFC 또는 플랫폼 자산의 손실로 이어질 수 있습니다.
공격자 모델
다음과 같은 공격자 패턴이 고려되었습니다:
악성 웹 페이지 제작자: 사용자 데이터, ID 또는 기타 프라이버시 민감 속성의 피싱,
가짜 ID와 공격 벡터를 통한 추가 피해를 유발하기 위한 NFC 태그 파괴 또는 수정.
악성 NFC 태그 제작자: 위와 동일하되, NFC 태그를 로컬에서 생성/삭제/수정할 수 있는
추가 가능성을 가짐. 그 결과 사용자 장치 무결성 손상, 데이터 주입, 악성 웹 페이지로의 리디렉션,
사용자 위치 피싱, 애플리케이션 설치와 같은 부수 행동 유발, 자동 디스패치 등 다른 동작 유발.
장치 또는 사용자 에이전트가 손상된 경우: 중간자(MITM) 공격:
Web NFC 구현과 사용자 장치의 NFC adapter 사이에서 발생하는 모든 형태의 MITM 공격.
수정되거나 재생된 NDEF 레코드를 제시하여 Web NFC를 사용하는 웹사이트와 상호작용을 시도하는 경우 포함.
위협
NFC 보안에 대한 소개는 여기
에서 확인할 수 있습니다. Web NFC에 대한 잠재적 위협은 아래와 같습니다.
지문 채취(Fingerprinting) 및 데이터 수집
위협 설명
악성 웹 페이지가 사용자 동의 없이 사용자 데이터, ID 또는 위치와 같은 기타 프라이버시 민감 속성을 수집하고
이를 제3자에게 노출(태그에 기록)합니다.
영향받는 자산
사용자 데이터, 사용자 ID 또는 기타 프라이버시 민감 속성
행위자
Web NFC를 사용하는 악성 웹 페이지 소유자, 악성 태그 소유자.
완화책 및 코멘트
사용자는 해당 웹 페이지에서 NFC로 공유될 수 있는 데이터가 무엇인지 인지할 수 있어야 합니다.
개인 데이터 접근에는 권한과 사용자 프롬프트를 사용하고, NFC에 노출되는 사용자 데이터를 최소화하세요.
NFC 태그는 사용자의 허가 없이 사용자의 장치가 웹사이트로 이동하도록 유도해서는 안 됩니다.
단, 사이트가 포그라운드에 있거나 포그라운드로 전환되어 권한이 부여된 경우는 예외입니다.
사용자 에이전트는
Geolocation API에 나열된 보안 및 프라이버시 조치를 고려해야 합니다.
NFC 태그 수정
위협 설명
사용자 동의 없이 NFC 태그가 수정되며, 읽기 전용으로 만들어져 되돌릴 수 없는 경우도 있습니다.
이는 악성 태그를 통한 추가 공격을 가능하게 하거나, 하나 이상의 태그를 사용 불가능하게 만드는
서비스 거부(DoS) 공격이 될 수 있습니다.
영향받는 자산
저장 상태의 NDEF 메시지 레코드(페이로드 및 헤더 포함).
행위자
악성 웹 페이지 제작자, 악성 사용자.
완화책 및 코멘트
태그에 쓰기 및 읽기 전용으로 만들기에는 권한과 사용자 프롬프트가 필요합니다.
또는 특정 웹 페이지가 쓸 수 있는 태그를 제한하세요. 예: 웹 페이지는 자신의 origin과
연결할 수 있는 태그에만 쓸 수 있음.
또는 덮어쓰기를 허용하되, 쓰면 안 되는 태그는 읽기 전용으로 보호하세요.
NFC 태그 수정을 감지하기 위해 NDEF signature를 사용하세요.
전송 중 NDEF 레코드 수정
위협 설명
Web NFC와 NFC adapter, 사용자 장치 사이에서 전송되는 NDEF record가
수정되어 다양한 중간자 공격이나 서비스 거부(DoS) 공격을 유발합니다.
또한 NDEF signature 레코드는 변경된 콘텐츠와 함께 제거되거나 교체될 수 있습니다.
기밀성을 보장하려면 페이로드 암호화와 안전한 통신을 사용하고,
Web NFC와 NFC adapter 간 데이터 교환, 인증 및 인가를 보장하세요.
악성 NFC 태그를 통한 능동 공격
위협 설명
악성 태그가 자의 또는 타의로 장치에 의해 읽힐 수 있으며, 읽힌 데이터가 사용자 에이전트에 대한
공격 벡터가 될 수 있습니다. 예를 들어 장치에서 동작을 트리거하려 시도할 수 있으며,
이는 악성 웹 사이트를 여는 것, 장치를 공격하도록 준비된 이미지를 여는 것 등 위협이 될 수 있습니다.
영향받는 자산
사용자 장치의 무결성, 기타 모든 Web NFC 자산.
행위자
악성 태그 제작자.
완화책 및 코멘트
이는 기존 모든 NFC 태그에서 일반적으로 존재하는 문제입니다.
데이터는 애플리케이션 특수 데이터로 간주됩니다.
구현에는 보안 강화가 필요합니다.
짧은 거리와 읽기 시 임계 각도, 포커스 요구 사항 때문에 비자발적 접촉 가능성은 낮습니다.
스마트 포스터 및 기타 태그에 대한 자동 동작은 허용되어서는 안 됩니다.
사용자에게 NFC 통신 중 발생하는 내용을 인지시키고 이를 제어할 수 있는 권한을 제공해야 합니다.
예: smart poster의 콘텐츠 열기, NFC handover를 통한 (악성일 수 있는) WiFi 자동 연결 등.
신뢰할 수 없는 NFC 태그에서의 동작은 허용하지 마십시오. 신뢰는 NDEF signature 검사로 수립할 수 있습니다.
구현을 위한 보안 메커니즘
권한 획득
구현은 예를 들어 사용자에 의해 명시적으로 부여된 권한과 같은 메커니즘을 사용하여 obtain permission 해야 합니다.
NFC 관련 권한을 구현하기 위해 UA가 [[[PERMISSIONS]]] API를 사용하는 것이 제안됩니다.
구현은 세션별/휘발성 권한을 사용할 수 있습니다.
NFC 동작 중 사용자 경고
구현은 웹 페이지가 NFC 어댑터에 접근할 때마다(예: 스캔이 진행 중일 때) 오버레이 대화상자를 표시하여
사용자에게 경고할 수 있습니다.
NFC를 통해 교환되는 데이터의 기밀성을 신뢰하려면, 애플리케이션은 공개키 기반구조(PKI)에 기반한 키 관리와 함께
암호화된 NFC content를 사용할 수 있습니다.
키 관리는 Web NFC의 범위를 벗어납니다.
NDEF 레코드 서명
NFC를 통해 교환되는 데이터의 무결성을 신뢰하려면, 사용자 에이전트는 키 관리에 공개키 기반구조를 사용하는
NDEF signature를 사용할 수 있습니다.
NDEF signature 버전 1.0([[NFC-SECURITY]])으로 서명된 태그의 경우,
서명은 NDEF 헤더의 첫 바이트를 제외하고 TYPE field, ID field, PAYLOAD field에만 적용되어
공격 표면을 남깁니다. [[NFC-SECURITY]] 버전 2.0은 서명에 태그 하드웨어 속성을 포함하고 더 짧은 인증서를 허용합니다.
편집자는 이 문서에 기여한 Jeffrey Yasskin, Anne van Kesteren,
Anssi Kostiainen, Domenic Denicola, Daniel Ehrenberg, Jonas Sicking,
Don Coleman, Salvatore Iovene, Rijubrata Bhaumik, Wanming Lin, Han Leon,
Ryan Sleevi, Balázs Engedy, Theodore Olsauskas-Warren, Reilly Grant,
Diego González, Daniel Appelquist께 감사드립니다.
웹 플랫폼에 NFC를 노출하는 초기 work와
현재 접근 방식에 대한 지원에 대해 Luc Yriarte와 Samuel Ortiz에게 특별한 감사를 전합니다.
또한 보안 및 프라이버시 섹션에 기여한 Elena Reshetova에게 특별한 감사를 전합니다.
