t t a s t a n d a r d 1. 표준의 목적 본 표준은 ttai.ko-12.0091 (2008년 12월 19일...

T T

A

S t a

n d

a r d

정보통신단체표준(국문표준)

TTAK.KO-12.0091/R1 제정일: 2009 년 12 월 22 일

수동형 RFID 보안태그와 리더의

인증 및 데이터 보호 프로토콜

Authentication and Data Protection Protocol

of Passive RFID Security Tag and Reader


TTAK.KO-12.0091/R1 제정일: 2009 년 12 월 22 일



Authentication and Data Protection Protocol

of Passive RFID Security Tag and Reader

본 문서에 대한 저작권은 TTA 에 있으며, TTA 와 사전 협의 없이 이 문서의 전체 또는 일부를

상업적 목적으로 복제 또는 배포해서는 안 됩니다.

Copyrightⓒ Telecommunications Technology Association 2009. All Rights Reserved.


i TTAK.KO-12.0091/R1

서 문

1. 표준의 목적

본 표준은 TTAI.KO-12.0091 (2008년 12월 19일 제정된 잠정표준)의 개정판이며, 저가

의 수동형 RFID 태그와 리더에 적합한 인증 및 데이터 보호 프로토콜을 정의한다.

2. 주요 내용 요약

주요 내용으로는 수동형 RFID 태그와 리더 간의 인증 및 데이터 통신채널 보호를 보

장하기 위한 프로토콜 규격으로서, ISO/IEC 18000-6 Type C 규격의 수동형 RFID 태그와

호환되면서 보안 기능이 강화된 수동형 RFID 보안태그를 구현할 수 있는 기술을 정의한

다.

즉, ISO/IEC 18000-6 Type C 수동형 RFID 태그에 추가적으로 AES 보안 모듈을 장착

시키고, 추가적인 명령/응답 메시지, 메모리맵 정보 및 보안 프로토콜을 정의하여 보안

기능 향상 및 호환성을 제공한다.

3. 표준 적용 산업 분야 및 산업에 미치는 영향

본 표준은 저가의 수동형 RFID 태그 및 리더와 관련된 사용자 프라이버시 보호, 통신

데이터 보호, 태그 인증을 제공할 수 있으므로 급격히 성장하는 RFID 산업의 발전과 관

련 응용서비스 활성화에 기여할 것이다.


TTAK.KO-12.0091/R1 ii

4. 참조 표준(권고)

4.1. 국외 표준(권고)

- ISO/IEC 18000-6 AM1, Information technology - Radio-Frequency Identification for

item management - Part 6: Parameters for air interface communications at 860 MHz

to 960 MHz, AMENDMENT 1: Extension with Type C and update of Types A and B,

2006-06-15.

4.2. 국내 표준

- TTA, TTAI.KO-12.0091, ‘수동형 RFID 보안태그와 리더의 인증 및 데이터 보호 프로토

콜’, 2008.12.19.

5. 참조표준(권고)과의 비교

5.1. 참조 표준(권고)과의 관련성

제품 아이디의 자동적이고 신뢰성 있는 인식을 위한 기술로서 RFID 태그 개발이 활발

히 진행되어 왔으며, ISO/IEC 18000-6 Type C 표준은 대표적인 UHF 대역의 저가 수동

형 RFID 태그 기술이다. 그러나, ISO/IEC 18000-6 Type C 표준은 태그 인증과 데이터

통신채널 보호가 취약하기 때문에 이를 극복해야 하는 과제를 안고 있다.

따라서 본 표준에서는 ISO/IEC 18000-6 Type C 표준과 호환성을 유지하면서 인증 및

데이터 보호가 가능한 프로토콜을 정의하며, 이를 위하여 추가적인 명령/응답 메시지, 메

모리맵 정보를 규정한다.

그리고, 2008년도에 잠정표준으로 제정된 TTAI.KO-12.0091이 지닌 보안 취약점인 스

푸핑 공격을 방어할 수 있는 향상된 프로토콜을 정의한다.


TTAK.KO-12.0091/R1 iii

5.2. 참조한 표준(권고)과 본 표준의 비교표

TTAK.KO-12.0091_R1 ISO/IEC 18000-6 Type C TTAI.KO-12.0091 비고

[4. 태그 메모리맵]

- Reserved, UII, TID, User

메모리 등 4 개 뱅크 수용

- Secure Area 뱅크

신규정의 추가

- Type C 태그는

Reserved, UII, TID, User

메모리 등 4 개 뱅크 정의됨

추가

[4.2 AESKey] (암호

알고리즘)

- 암호 알고리즘 사용 방식

신규정의 추가

- 없음 추가

[5. 명령/응답 메시지]

- 14 개 명령어 수용

- 보안 프로토콜 동작과

관련된 4 개 보안 명령

신규정의 추가

- 14 개 명령 정의됨

- 14 개 명령 정의됨

- 보안 프로토콜 동작과

관련된 5 개 보안 명령

신규정의 추가

추가/수정

[6. 보안 프로토콜]

- 보안 프로토콜 동작 방식

신규정의 추가

- 없음 추가

[6. 보안 프로토콜] (세션

키 생성 방법)

- 스푸핑 공격을 방어를

위해 세션 키 신선도를

보장할 수 있도록 리더의

RNint 와 태그의 RNtag 를

세션 키 생성에 사용함

- 없음

- 세션 키 생성에 사용되는

랜덤넘버는 태그의

Key_RN 임

수정


TTAK.KO-12.0091/R1 iv

6. 지적 재산권 관련 사항

본 표준의 ‘지적 재산권 확약서’ 제출 현황은 TTA 웹사이트에서 확인할 수 있다.

※본 표준을 이용하는 자는 이용함에 있어 지적 재산권이 포함되어 있을 수 있으므로,

확인 후 이용한다.

※본 표준과 관련하여 접수된 확약서 이외에도 지적 재산권이 존재할 수 있다.

7. 시험 인증 관련 사항

7.1. 시험 인증 대상 여부

- 해당 사항 없음

7.2. 시험 표준 제정 현황


8. 표준의 이력 정보

8.1. 표준의 이력

판 수 제정개정일 제정개정 내역

제1판 2008.12.19. 제정

TTAK.KO-12.0091

제2판 2009.12.22. 개정

TTAK.KO-12.0091/R1

8.2. 주요 개정 사항



TTAK.KO-12.0091/R1 v

Preface

1. Purpose of Standard

This standard is a revision of the TTAI.KO-12.0091. To provide the communication

data protection and the mutual authentication, this standard defines the security

protocol suitable for the cheap passive RFID tag and reader.

2. Summary of Contents

This is the security protocol standard for guaranteeing an authentication between the

tag and a reader and data communication channel protection. This standard defines

the technology implementing the passive RFID security tag and the reader in which the

security function is strengthened. And this standard is compatible with the passive

RFID tag of the ISO/IEC 18000-6 Type C standard.

That is, this standard provides the additional command/response message, the

memory map information, and the security protocol which uses the command/response

message and the memory map information.

3. Applicable Fields of Industry and its Effect

Since this standard can provide the user's privacy protection, the communication

data protection, and the tag authentication related to the cheap passive RFID tag and

reader, it will contribute to the application service activation in the RFID industry which

it drastically grows.


TTAK.KO-12.0091/R1 vi

4. Reference Standards(Recommendations)

4.1. International Standards(Recommendations)

- ISO/IEC 18000 Information technology - Radio-Frequency Identification for item

management-Part 6: Parameters for air interface communications at 860 MHz to 960

MHz Amendment (FPDAM 1), 2006.

4.2. Domestic Standards

- TTA, TTAI.KO-12.0091, “Authentication and Data Protection Protocol of Passive RFID

Security Tag and Reader”, 2008.12.19.

5. Relationship to Reference Standards(Recommendations)

5.1. Relationship of Reference Standards(Recommendations)

The RFID tag is actively being developed as the technology for automatic and

trustworthy recognition of the product ID. ISO/IEC 18000-6 Type C standard is the

representative UHF passive RFID tag technology. But, because the tag authentication

and communication data protection are weak, the ISO/IEC 18000-6 Type C standard

embraces the subject which has to overcome this weakness.

Therefore, this standard is compatible with the passive RFID tag of the ISO/IEC

18000-6 Type C standard and defines the additional command/response message, the

memory map information, and the security protocol.

And, this standard defines security-enhanced protocols protecting users from the

spoofing attack which is a weak point of TTAI.KO-12.0091.


TTAK.KO-12.0091/R1 vii

5.2. Differences between Reference Standard(Recommendation) and this Standard

TTAK.KO-12.0091/R1 ISO/IEC 18000-6 Type C TTAI.KO-12.0091

[4. Tag memory map]

- Compatible with 9.3.2.1

of ISO/IEC 18000-6 AM1

- Added Secure bank

- Four banks consisting of

Reserved, UII, TID, and

User

added

[4.2 AESKey] (Cipher

algorithm)

- Added cipher algorithm

- Nothing added

[5. Command/response

message]


of ISO/IEC 18000-6 AM1

- Added 4 security

commands

- 14 commands


of the reference standard

- Added 5 security

commands

added/

modified

[6. Security protocol]

- Added security protocol - Nothing added

[6. Security protocol]

(Session key generation)

- Both of RNint of reader

and RNtag of tag are used

for session key generation,

which can ensure the key

freshness

- Nothing

- Key_RN of tag is only

used for session key

generation

modified

6. Statement of Intellectual Property Rights

IPRs related to the present document may have been declared to TTA. The

information pertaining to these IPRs, if any, is available on the TTA Website.

No guarantee can be given as to the existence of other IPRs not referenced on the

TTA website.

And, please make sure to check before applying the standard.


TTAK.KO-12.0091/R1 viii

7. Statement of Testing and Certification

7.1. Object of Testing and Certification

- None

7.2. Standards of Testing and Certification

- None

8. History of Standard

8.1. Change History

Edition Issue Date Outline

The 1st edition 2008.12.19. Established

TTAK.KO-12.0091

The 2nd edition 2009.12.22. Revised

TTAK.KO-12.0091/R1

8.2. Revisions

- None


TTAK.KO-12.0091/R1 ix

목 차

1. 개 요 ··························································································· 1

2. 표준의 구성 및 범위 ········································································· 2

3. 용어 정의 및 약어 ············································································ 3

4. 태그 메모리맵 정보 ·········································································· 5

4.1. SecParam과 KI ········································································· 6

4.2. AESKey ··················································································· 8

5. 명령/응답 메시지 ············································································ 11

5.1. Sec_ACK 명령/응답 메시지 ·························································· 11

5.2. Sec_ReqRN 명령/응답 메시지 ······················································· 12

5.3. Req_Auth 명령/응답 메시지 ························································· 13

5.4. Get_Auth 명령/응답 메시지 ·························································· 13

6. 보안 프로토콜 동작 ········································································· 15

6.1. 상호 인증 및 데이터 보호 프로토콜 ··············································· 15

6.2. 태그 인증 프로토콜 ··································································· 17

부록 Ⅰ. 보안성 분석 ··········································································· 21

Ⅰ.1. 보안성 분석의 목적 ································································ 21

Ⅰ.2. [6.1. 상호 인증 및 데이터 보호 프로토콜] 보안성 분석 ···················· 21

Ⅰ.3. [6.2. 태그 인증 프로토콜] 보안성 분석 ········································ 25

Ⅰ.4. 알려진 취약점 ······································································ 29

부록 Ⅱ. 키 공유 방법 ·········································································· 31

Ⅱ.1. [6.1. 상호 인증 및 데이터 보호 프로토콜] 키 공유 방법 ··················· 31

Ⅱ.2. [6.2. 태그 인증 프로토콜] 키 공유 방법 ······································ 31

부록 Ⅲ. 암/복호화 pseudo code ···························································· 33


TTAK.KO-12.0091/R1 x

Contents

1. Introduction ······················································································ 1

2. Constitution and Scope ········································································ 2

3. Terms and Definitions ·········································································· 3

4. Tag Memory Map Information································································· 5

4.1. SecParam and KI ·········································································· 6

4.2. AESKey ······················································································ 8

5. Command/Response Message ······························································ 11

5.1. Sec_ACK Command/Response ························································ 11

5.2. Sec_ReqRN Command/Response ····················································· 12

5.3. Req_Auth Command/Response ························································ 13

5.4. Get_Auth Command/Response ························································ 13

6. Security Protocol ··············································································· 15

6.1. Mutual Authentication and Data Protection Protocol ······························ 15

6.2. Tag Authentication Protocol ··························································· 17

Appendix Ⅰ. Security Analysis ································································· 21

Ⅰ.1. Purpose ········································································· 21

Ⅰ.2. [6.1. Mutual Authentication and Data Protection Protocol] Analysis · 21

Ⅰ.3. [6.2. Tag Authentication Protocol] Analysis ······························ 25

Ⅰ.4. Known Vulnerabilities ························································· 29

Appendix Ⅱ. Key Sharing ······································································· 31

Ⅱ.1. [6.1. Mutual Authentication and Data Protection Protocol] Sharing ·· 31

Ⅱ.2. [6.2. Tag Authentication Protocol] Sharing ······························· 31

Appendix Ⅲ. Enc/Decryption pseudo code ·················································· 33


１ TTAK.KO-12.0091/R1

수동형 RFID 보안태그와 리더의 인증 및 데이터 보호 프로토콜

(Authentication and Data Protection Protocol

of Passive RFID Security Tag and Reader)

1. 개요

본 표준은 저가의 수동형 RFID 태그와 리더에 적합한 인증 및 데이터 보호 프로토콜

을 정의한다. 활용될 응용을 고려하여 2가지 프로토콜을 정의한다.

하나는 태그와 리더의 상호 인증 및 데이터 보호 프로토콜로서, 이는 개인 의료카드나

개인 소유물 등에 수동형 RFID 태그가 부착되어 있는 경우에 개인 프라이버시 보호 및

데이터 보호를 위해 사용될 수 있다. 이 프로토콜에서는 태그와 리더가 일대일 통신을

수행하는 참여주체이며 동일한 마스터 키를 공유하고 있다고 가정한다. 즉, 키 공유 기술

은 본 표준의 영역이 아니다. 이 프로토콜에서 사용되는 암호화 기법은 대칭키 방식이며,

태그와 리더의 상호 인증, 데이터 기밀성, 스푸핑 공격 방지 및 태그의 UII (Unique Item

Identification) 노출 방지를 통한 프라이버시 보호 등의 보안 서비스 제공이 가능하다.

또 다른 하나는 태그 인증 프로토콜로서, 이는 임의의 리더가 태그 진위 여부를 확인

하는 프로토콜이며 진품 확인 서비스에 사용될 수 있다. 이 프로토콜에서는 태그, 리더

및 인증서버가 참여주체이며 태그와 인증서버가 동일한 마스터 키를 공유한다고 가정한

다. 이 프로토콜에서는 리더는 마스터 키를 가지지 않으며 인증서버로부터 태그 인증 성

공 여부만을 수신한다. 이 프로토콜에서도 키 공유 기술은 표준 정의의 대상이 아니다.

이 프로토콜에서 사용되는 암호화 기법도 대칭키 방식이며, 태그 인증, 스푸핑 공격 방지

의 보안 서비스 제공이 가능하다. 그러나 이 프로토콜에서는 태그와 리더 구간에 데이터

암호화가 없고 태그의 UII 자체가 공개되기 때문에 데이터 기밀성 및 프라이버시 보호의

보안 서비스는 제공하지 못한다.


TTAK.KO-12.0091/R1 ２

2. 표준의 구성 및 범위

본 표준은 수동형 RFID 태그와 리더 간의 인증 및 통신 데이터 보호를 보장하기 위한

프로토콜 규격으로서, ISO/IEC 18000-6 Type C 규격의 수동형 RFID 태그와 호환되면서

보안 기능이 강화된 수동형 RFID 보안태그를 구현할 수 있는 기술을 정의하며 크게 세

개의 장으로 구성되어 있다.

첫 번째로 수동형 RFID 태그에 추가되어야 하는 새로운 메모리맵 정보를 정의한다.

두 번째로 2가지 보안 프로토콜과 관련되어 새롭게 추가되어야 하는 명령/응답 메시지

를 정의한다.

세 번째는 새롭게 정의된 메모리맵 정보와 명령/응답 메시지를 사용하여 2가지 보안

프로토콜 절차를 정의한다.

즉, ISO/IEC 18000-6 Type C 수동형 RFID 태그와 리더에 추가적인 명령/응답 메시지,

메모리맵 정보 및 보안 프로토콜을 정의하여 보안 기능 향상 및 호환성을 제공한다.

그리고, 부록 A에서는 본 표준에서 정의한 2가지 보안 프로토콜에 대한 보안성 분석

내용을 첨부한다. 본 표준의 보안 프로토콜이 제공할 수 있는 보안 서비스는 부록 A의

보안성 분석을 참조하면 된다.

부록 B는 본 표준에서 정의한 2가지 보안 프로토콜에서 사용할 수 있는 키 공유 아이

디어에 대해 기술한다. 단 키 공유 기술의 정의는 본 표준의 범위가 아니므로 부록 B는

단순한 정보제공 차원의 내용이 될 것입니다

부록 C는 본 표준의 암/복호화 연산에 대한 pseudo code를 기술한다. 이는 암/복호화

방식에 대한 독자의 이해를 돕기 위함이다.


TTAK.KO-12.0091/R1 ３

3. 정의

3.1. 용어 정의

3.1.1. RFID (Radio Frequency Identification)

전파 식별로 해석되며, 전파 신호를 통해 비접촉식으로 자신의 아이디를 전달하는

디지털 기술을 의미함. RFID 시스템은 판독 및 해독 기능을 하는 판독기(RFID

reader)와 고유 정보를 내장한 태그(RFID tag), 운용 소프트웨어 및 네트워크로 구

성되며, 전파 신호를 통해 비접촉식으로 사물에 부착된 얇은 평면 형태의 태그를

식별하여 정보를 처리하는 시스템임.

3.1.2. 태그 (Tag)

본 표준에서 언급하는 태그는 ISO/IEC 18000-6 Type C에서 규정하는 900MHz 대

역 무선 인터페이스를 갖는 RFID 시스템에서의 태그를 의미함. 일반적인 RFID 태

그는 기존의 바코드 대신 상품이나 대상물에 부착되어 각종 정보를 담은 칩과 안

테나로 구성됨.

3.1.3. 리더 (Reader)

본 표준에서 언급하는 리더는 ISO/IEC 18000-6 Type C에서 규정하는 900MHz 대

역 무선 인터페이스를 갖는 RFID 시스템에서의 리더를 의미함. 일반적인 RFID 리

더는 태그의 정보를 활용하기 위해 태그와 송수신하거나 태그에서 수집된 정보를

백엔드 시스템으로 전송하는 장치임. 본 표준의 리더는 태그의 UII와 관련되는 마

스터 키 및 키 인덱스를 안전하게 저장하며, 해당 태그의 UII와 관련이 없는 마스

터 키 및 키 인덱스를 이용한 인증 시도는 오류로 처리하는 기능을 가짐.


TTAK.KO-12.0091/R1 ４

3.1.4. 인증서버 (Authentication Server)

본 표준에서 언급하는 인증서버는 일종의 데이터베이스 서버이며, 태그의 UII와

관련되는 마스터 키 및 키 인덱스를 안전하게 저장하고 있는 서버를 의미함. 기능

적으로는 리더로부터 인증 관련된 데이터를 수신하여 태그에 대한 인증 여부를 판

단하여 회신하는 기능을 수행함. 본 표준의 인증서버는 해당 태그의 UII와 관련이

없는 마스터 키 및 키 인덱스를 이용한 인증 시도는 오류로 처리하는 기능을 가짐.

3.1.5. 워드 사이즈 (Word size)

본 표준에서 언급하는 워드 사이즈는 16 비트 크기를 의미함. 태그의 메모리 뱅크

구조에서 하나의 블록을 워드 사이즈로 표현하여 설명하고 있음.

3.2. 약어 정의

ACK Acknowledgement

AES Advanced Encryption Standard

CRC Cyclic redundancy Check

EBV Extensible Bit Vectors

KI Key Index

KS Key Setting

NC Num of Challenge

NK Num of KI

NR Num of Round

PC Protocol Control

RFID Radio Frequency Identification

RFU Reserved for Future Use

RN Random Number


TTAK.KO-12.0091/R1 ５

SM Security Mode

UII Unique Item Identification

XPC eXtened Protocol Control

4. 태그 메모리맵 정보

ISO/IEC 18000-6 Type C 태그는 그림 1의 왼편과 같은 메모리맵을 가지며, 본 수동형

보안 태그는 추가로 (그림 4-1)의 오른편과 같은 Secure Area 메모리 뱅크의 정의가 필

요하다.

Secure Area 메모리는 SecParam(Security Parameter), AESKey와 KI(Key Index)를 담

으며, 기존의 일반 리더에 의해서는 읽혀져서는 안된다. Secure Area 메모리 뱅크는

AESKey와 KI의 업데이트 변경을 위해 이중화 구조를 가져야 한다. 즉, 두 개의 Secure

Area 메모리 뱅크로 구현되어야 한다. (그림 4-1)의 오른편에 보이는 것처럼 동일한 구

조가 반복되어 있는데, 하단에 보이는 주소 00h 부터 0Fh 블록에서 시작되는 Secure

Area가 현재 사용하는 AESKey 관련한 메모리이며, 상단의 Secure Area는 업데이트를 위

한 AESKey 정보를 가진 메모리이다.

(그림 4-1)의 메모리 뱅크는 각 블록의 가로 크기가 1 워드 (즉, 16 비트) 사이즈를 가

진다. 따라서 (그림 4-1)에서 보는 바와 같이 SecParam은 명시적으로 16 비트이고, KI

는 SecParam의 특정 필드(Num of KI) 값에 따라 가변적인 크기를 가진다. 만일 KI가 1

워드의 길이를 가진다고 정의되면 16 비트의 KI[15:0] 하나만 존재한다. 그리고, AESKey

는 총 128 비트(즉, 8 워드)이므로 하나의 블록이 아니라 8개의 블록에 위치한다. 즉,

AESKey[15:0] 부터 AESKey[127:112] 까지를 연접한 값이 128 비트 마스터 키 하나를

구성한다. KI 역시 2 워드 이상의 길이를 가지게 될 경우에는 KI[15:0] 부터 마지막 KI

블록까지 연접한 값을 KI로 사용한다.


TTAK.KO-12.0091/R1 ６

00h

00h

10h

20h

0Fh

1Fh

2Fh

MSB LSB

Bank 11

Bank 10

Bank 01

Bank 00 RESERVED

UII

TID

USER

CRC- 16 [15:0]

UII [15:0]

UII [N:N-15]

…

20h

0Fh

1Fh

2Fh

MSB LSB

30h 3Fh

10h

Access Passwd [15:0]

Kill Passwd [15:0]

Access Passwd [31:16]

Kill Passwd [31:16]

…

00h

10h

0Fh

1Fh

MSB LSB

TID [31:16]

TID [15:0]

…

PC [15:0]

SecParam + AESKey + KI

Secure Area

New Bank or

Specific Bank

0Fh00h

1Fh10h

AESKey[31:16]

CRC-16[15:0]

AESKey[47:32]

AESKey[63:48]

AESKey[79:64]

AESKey[95:80]

AESKey[111:96]

AESKey[127:112]

AESKey[15:0]

SecParam[15:0]

KI[(NK -1):(NK -16)]

...

KI[15:0]

AESKey[31:16]

CRC-16[15:0]

AESKey[47:32]

AESKey[63:48]

AESKey[79:64]

AESKey[95:80]

AESKey[111:96]

AESKey[127:112]

AESKey[15:0]

SecParam[15:0]

KI[(NK -1):(NK -16)]

...

KI[15:0]

MSB LSB

(그림 4-1) 수동형 RFID 보안태그 메모리맵 구조

4.1. SecParam 과 KI

SecParam은 (그림 4-2)와 같이 1 비트 SM(Secure Mode), 1 비트 KS(Key Setting), 2

비트 RFU(Reserved for Future Use), AES(Advanced Encryption Standard) 라운드 수를

지시하는 4 비트, Challenge 수를 지시하는 4 비트, 그리고 키 인덱스 블록의 개수를 지

시하는 4 비트로 구성되어 있다. 각 필드 별 의미는 다음과 같다.

... ...

0 1 2 3 4 5 6 7 8 9 A B C D E F

KI(0) Key Index [(NK -1):(NK -16)]

SecParamNum of Challenge [3:0]

(NC Word)SM RFU[1:0] : 00

Num of Round [3:0]

(NR Round)

Num of KI [3:0]

(NK Word)KS

KI(NK -1) Key Index [15:0]

(그림 4-2) SecParam과 KI 구조


TTAK.KO-12.0091/R1 ７

SM(Secure Mode) : 태그가 보안 기능을 지원하는지 여부를 알려주는 지시자로서, 태그

가 보안 기능을 지원하는 경우에 1로 셋팅되고, 그렇지 않은 경우에 0으로 셋팅된다.

SecParam[0]에 위치하며 1 비트로 구성되어 있다.

KS(Key Setting) : 태그에 AESKey가 설정되어 있는지 여부를 알려주는 지시자로서,

AESKey가 설정되어 있으면 1로 셋팅되고, 그렇지 않은 경우에 0으로 셋팅된다.

SecParam[1]에 위치하며 1 비트로 구성되어 있다.

RFU(Reserved for Future Use) : 2 비트의 예약 비트이다. SecParam[2:3]에 위치한다.

Num of Round : 이 값은 태그에서 사용되는 AES 라운드 수를 나타낸다. 본 표준에서

는 NR의 약어로 사용된다. 디폴트 값은 AES 전체 라운드 수인 10 이다. 세션 키 생성을

위해 AES 암호화 라운드를 수행시키는데 ISO/IEC 18000 Type C 표준에서의 회신 타이

밍 요구사항을 맞추기 위해서 태그에서 10보다 작은 수의 라운드를 사용할 수 있다.

SecParam[4:7]에 위치하며 4 비트로 구성되어 있다.

Num of Challenge : 이 값은 워드 사이즈로 표현된 태그가 지원하는 Challenge 데이터

의 길이이다. 본 표준에서는 NC의 약어로 사용된다. Challenge 데이터는 태그 인증을 위

해 리더에서 랜덤하게 생성된다. 디폴트 값은 1이며, 이는 inventory 과정에서 1 워드의

Challenge 데이터를 사용한다는 것을 의미한다. 본 표준 6장에서 정의하는 프로토콜의

인증용 랜덤넘버인 CHint와 CHtag의 길이를 유추할 수 있도록 워드 사이즈를 알려주는

값으로서, 만약 이 값이 2라면 2 워드, 즉 32 비트 CHint와 CHtag를 사용한다는 것을

의미한다. SecParam[8:B]에 위치한 4 비트로 구성되어 있다.


TTAK.KO-12.0091/R1 ８

Num of KI : 이 값은 워드 사이즈로 표현된 키 인덱스의 개수이다. 본 표준에서는 NK의

약어로 사용된다. 디폴트는 1이며, 이는 1 워드에 해당하는 키 인덱스 값이 가능함을

의미한다. 즉, 이 경우에는 총 65,536개의 키 풀(key pool)이 존재할 수 있음을 의미한다.

만약 값이 2 라면 키 풀의 크기는 232 까지 가능함을 의미한다. 그리고 KI 메모리의 실제

값이 해당 키의 키 인덱스를 나타낸다. SecParam[C:F]에 위치한 4 비트로 구성되어 있

다.

KI (Key Index) : 본 표준에서는 효율적인 키 관리를 위하여 키 풀 사용을 고려한다. 이

값은 키 풀에서의 키 인덱스를 지시한다. KI는 리더에 의해 태그에 설정되며 변경될 수

있다. Num of KI 필드의 값에 따라 가변적인 크기를 가진다.

4.2. AESKey

AESKey는 Secure Area 뱅크에 저장되는 128 비트 AES 비밀키이며, 이는 세션 키 생

성을 위한 마스터 키 역할을 한다. AES 기반 보안 모듈을 장착한 수동형 보안 태그의 세

션 키 생성 방법은 (그림 4-3)에서 묘사하고 있고, 암/복호화 방법은 (그림 4-4)와 (그림

4-5)에서 보이고 있다.

세션 키 생성에서 AESKey는 마스터 키, RNint와 RNtag의 확장된 128 비트는 최초 초

기값(initial value) 역할을 한다. 이 때 RNint와 RNtag는 각각 16 비트 크기를 가지고 있

기 때문에 128 비트의 초기값으로 입력되기 위해서 RNint와 RNtag를 연접한 후 동일한

비트를 반복시키는 방법으로 128 비트로 확장한다. 즉, (RNint || RNtag)의 32 비트를 4

번 반복한다. 그리고, SecParam에서의 라운드 수에 따라 Key Generator 블록에서 AES

암호화 라운드를 수행하여 128 비트 세션 키를 생성한다. 그 다음부터는 생성된 세션 키

가 다시 키 생성 루틴에 활용된다. 데이터 암/복호화는 생성된 세션 키가 스트림 암호화

방식처럼 사용된다. 이러한 구조로 표준화하는 이유는 수동형 RFID 태그의 연산 부담을

줄이기 위함이다.

본 표준에서는 수동형 RFID 태그의 응답 시간을 고려하여 수동형 RFID 태그에 적합한

AES 세션 키 생성 및 암/복호화 방법을 정의하였지만, 향후 수동형 RFID 태그의 응답


TTAK.KO-12.0091/R1 ９

시간을 만족하는 국내 암호 알고리즘인 SEED, ARIA 등도 적용될 수 있을 것이다. 즉, 수

동형 RFID 태그에 최적화된 형태의 SEED와 ARIA의 세션 키 생성, 암/복호화 방법 및

보안 프로토콜의 정의는 구현 가능성 및 성능 우수성 등을 고려하여 차기 버전 또는 별

도의 표준에서 규정될 수 있다.

AES Key (128Bits)

(AESKey : Set by Reader)

First Initial Vector (128bits)

(RNint||RNtag || RNint||RNtag || RNint||RNtag || RNint||RNtag )

AES Crypto Module

SecParam

(NR)

Next Initial Vector

Session Key [2] (128bits)

Session Key [1] (128bits)

A New Session Key is created

Whenever the Pointer of a

Session Key is turnaround

Output

Pointer (0)

(그림 4-3) 세션 키 생성 방법

plaintext

Session Key (128bits)

Pointer

Encryption

XOR

per bit

Creating and

adding of

CRC16

Pointer (0)

Bit Stream Output

CM

Creating and

adding of

Command

header

Italic: ciphertext

CRC16

Ciphertext

(그림 4-4) 암호화 방법


TTAK.KO-12.0091/R1 １０

plaintext

Session Key (128bits)

Pointer

Decryption

XOR

per bit

Analyzing and

removing of

Command

header

Pointer (0)

Bit Stream input

CRC16

Checking and

removing of

CRC16

Italic: ciphertext

CM

Ciphertext

(그림 4-5) 복호화 방법


TTAK.KO-12.0091/R1 １１

5. 명령/응답 메시지

수동형 보안 태그를 위해서는 다음과 같은 명령 메시지를 정의해야 한다.

- Sec_ACK 명령과 응답 메시지 (명령어 코드 0xE101)

- Sec_ReqRN 명령과 응답 메시지 (명령어 코드 0xE102)

- Req_Auth 명령과 응답 메시지 (명령어 코드 0xE103)

- Get_Auth 명령과 응답 메시지 (명령어 코드 0xE104)

5.1. Sec_ACK 명령/응답 메시지

Sec_ACK 명령은 세션 키 생성에 사용되는 리더의 RNint를 전달하는 역할을 수행하는

명령으로 그 구성은 (그림 5-1)과 같다.

Sec_ACK 명령 코드 값은 0xE101을 사용한다. 태그는 Sec_ACK 명령에 대한 응답으

로 SecParam, KI, 그리고 RNtag를 회신한다. 여기서 KI는 SecParam의 Num of KI 필드

의 값에 따라 가변적인 길이로 응답되는데, 그 길이는 (16 * Num of KI) 비트가 된다. 본

명령과 응답은 세션 키 생성에 사용되는 RNint와 RNtag를 교환하는 역할과 태그가 AES

암호 모듈을 구동시킬 수 있는 시간을 벌기 위한 역할을 하며, 평문으로 전달된다.

Command RNint RN16 CRC-16

# of bits 16 16 16 16

description 0xE101 random number handle

Sec_ACK Command

SecParam KI RNtag RN16 CRC-16

# of bits 16 16 * (Num of KI) 16 16 16

description security parameter key index random number handle

Sec_ACK Reply: Encrypted Data

: Plain Data

(그림 5-1) Sec_ACK 명령/응답


TTAK.KO-12.0091/R1 １２

5.2. Sec_ReqRN 명령/응답 메시지

Sec_ReqRN 명령은 ISO/IEC 18000-6 Type C 표준의 Req_RN 명령처럼 태그의 state

를 Open Status로 천이시킨다. Sec_ReqRN 명령과 응답은 태그와 리더의 상호 인증을

위한 Challenge/Response를 주고받는 동작이며, 그 구성은 (그림 5-2)와 같다.

Sec_ReqRN 명령어 코드는 0xE102이며, 명령과 응답의 페이로드 부분은 모두 암호화

되어 전달된다. 본 명령과 응답은 6.1절의 상호 인증 및 데이터 보호 프로토콜에서 사용

된다. Sec_ReqRN 명령에서 Challenge에 해당하는 CHint 값은 리더가 랜덤하게 생성한

Nonce 이며 SecParam의 Num of Challenge 필드의 값에 따라 (16 * Num of Challenge)

비트의 가변적인 길이를 가진다. 태그 응답의 Response 값은 리더로부터 전달받은

CHint를 태그가 암호화한 값이다. 응답을 받은 리더는 응답을 복호화한 후, 자신의

CHint 값이 Response 값으로 돌아온 것을 확인하여 태그를 인증한다. 또한 태그는 수신

된 명령에서 리더가 올바른 RN16의 암호문을 전송한 것을 확인하여 리더를 인증한다.

본 Challenge/Response를 통해 Replay 공격 방지와 상호 인증을 달성할 수 있다. 여기

서, 명령어 타입과 CRC(Cyclic redundancy Check)-16 값은 암호화 되지 않는다.

Command CHint RN16 CRC-16

# of bits 16 16 * (Num of Challenge) 16 16

description 0xE102 random number handle

Sec_ReqRN Command

Response RN16 CRC-16

# of bits 16 * (Num of Challenge) 16 16

description CHint handle

Sec_ReqRN reply

: Encrypted Data

: Plain Data

(그림 5-2) Sec_ReqRN 명령/응답


TTAK.KO-12.0091/R1 １３

5.3. Req_Auth 명령/응답 메시지

Req_Auth 명령은 태그 인증을 위한 인증 데이터를 요청하기 위하여 6.2절의 태그 인

증 프로토콜에서 사용되는 명령으로 그 구성은 (그림 5-3)과 같다.

Req_Auth 명령어 코드는 0xE103이며, 리더가 보내는 명령은 세션 키 생성에 사용되는

리더의 RNint, Challenge에 해당하는 CHint를 포함하며, 이들은 평문으로 전송된다.

CHint 값은 리더가 랜덤하게 생성한 Nonce 이며 SecParam의 Num of Challenge 필드의

값에 따라 (16 * Num of Challenge) 비트의 가변적인 길이를 가진다. 태그에서는 세션

키 생성을 위한 태그의 RNtag를 생성하여 응답하며, 내부적으로 RNint와 RNtag를 사용

하여 세션 키를 생성한다. 그리고 5.4절에서 설명하는 Get_Auth 명령을 기다린다.

Command RNint CHint RN16 CRC-16

# of bits 16 16 16 * (Num of Challenge) 16 16

description 0xE103 random number random number handle

Req_Auth Command

RNtag Handle CRC-16

# of bits 16 16 16

description random number handle

Req_Auth reply

: Encrypted Data

: Plain Data

(그림 5-3) Req_Auth 명령/응답

5.4. Get_Auth 명령/응답 메시지

Get_Auth 명령은 태그 인증을 위한 인증 데이터를 가져오기 위하여 6.2절의 태그 인증

프로토콜에서 사용되는 명령으로 그 구성은 (그림 5-4)와 같다. 인증 데이터를 요청하는

Req_Auth 명령과 인증 데이터를 가져오는 Get_Auth 명령을 구분하여 사용하는 이유는

태그에서 RNint와 RNtag로부터 세션 키를 생성하는 시간을 벌기 위함이다. 즉, 태그가

리더로부터 RNint를 수신하고 RNtag를 생성 후 이로부터 세션 키 생성하여 암호화된 데


TTAK.KO-12.0091/R1 １４

이터를 만들어서 응답하게 되면 수동형 RFID 태그의 제한적인 연산 능력 때문에

ISO/IEC 18000-6 Type C 표준의 태그 응답시간을 만족하기 어렵게 된다. 따라서, 인증

데이터 요청 후 다시 인증 데이터를 가져오는 명령으로 두번의 실행으로 동작하도록 표

준화하는 것이 대안이 될 수 있다.

Get_Auth 명령어 코드는 0xE104이며, 리더가 보내는 명령은 handle 만을 포함하며,

평문으로 전송된다. 태그는 Challenge에 해당하는 CHtag와 인증 데이터인 Auth_Data를

암호화하여 회신한다. 즉, 태그 인증 프로토콜에서는 리더가 마스터 키를 가지고 있지 않

기 때문에 리더의 명령은 암호화될 수 없지만 태그는 자신의 마스터 키를 사용하여 세션

키 생성과 암호화 동작을 수행할 수 있다. 태그가 보낸 암호화된 CHtag와 Auth_Data는

서버로 전달된 후 서버에서 복호화된다. Auth_Data는 CHint와 CHtag를 XOR 한 후 이

값을 암호화한 것이다. CHint 값은 리더가 랜덤하게 생성한 Nonce 이고 CHtag 값은 태

그가 랜덤하게 생성한 Nonce 인데, SecParam의 Num of Challenge 필드의 값에 따라

(16 * Num of Challenge) 비트의 가변적인 길이를 가진다. 또한 Auth_Data 역시 CHint와

CHtag 길이와 마찬가지로 가변적인 길이를 가진다.

CHtag Auth_Data Handle CRC-16

# of bits 16 * (Num of Challenge) 16 * (Num of Challenge) 16 16

description random number CHint CHtag handle

Get_Auth Command

Command Handle CRC-16

# of bits 16 16 16

description 0xE104 handle

Get_Auth reply

: Encrypted Data

: Plain Data

(그림 5-4) Get_Auth 명령/응답


TTAK.KO-12.0091/R1 １５

6. 보안 프로토콜 동작

6.1. 상호 인증 및 데이터 보호 프로토콜

상호 인증 및 데이터 보호 프로토콜 절차는 (그림 6-1)과 같다. 본 프로토콜에서는 태

그와 리더가 마스터 키를 공유하고 있다고 가정한다. 태그는 가장 먼저 리더로부터

Wake-up 신호를 받아서 깨어나게 된다. 깨어난 태그는 다음과 같은 절차에 따라 상호

인증 및 데이터 보호 프로토콜을 수행한다.

태그리더

Query/Adjust/Rep

RN16

Sec_ACK(RNint, RN16)

(1)

(5)

(2)

(6)

PC, XPC, UII

SecParam, KI, RNtag

Checking CHint.

If OK, Authentication of tag

ACK(RN16)

Sec_ReqRN(CHint, RN16)

(8)

Rep(CHint, Handle)

(10)

Returning CHint

(3)

(11)

(10)

(9)

: Ciphertext

: Plaintext

(8)

Starting encryption

(6)

1. RNtag is a random number for

generating session key

2. Generating session key using

RNint and RNtag

(9)

Sending CHint

Other command(Handle)

Reply(12)

Checking RN16.

If OK, Authentication of interrogator

(5)

RNint is a random number for

generating session key

Select(0)

PC, XPC, Void UII(4)

ACK(RN16)(7)(7)

Generating session key using

RNint and RNtag

(그림 6-1) 상호 인증 및 데이터 보호 프로토콜

단계 (0) ~ 단계(3): 기존의 ISO/IEC 18000-6 Type C 표준의 동작과 동일하다. 단계

(3)의 ACK 명령은 태그에게 UII(Unique Item Identification)를 요청하는 명령이다. 세분화

하여 설명하면, (0) Select로 태그 그룹을 선택하고, (1) 리더가 태그에게 쿼리 메시지를

전송한다. Query, Query_Adjust, Query_Rep 등은 ISO/IEC 18000-6 Type C에 정의되어

있는 명령이다. 쿼리 메시지를 받은 태그는 (2) 랜덤넘버(RN16)를 회신한다. RN16를 받

은 리더는 (3) ACK 메시지를 전송한다.


TTAK.KO-12.0091/R1 １６

단계 (4): 본 프로토콜을 따르는 태그는 ACK 명령에 대한 응답으로 PC(Protocol

Control), XPC(eXtended Protocol Control), 그리고 Void UII를 회신한다. 여기서 Void UII

는 진짜 UII와 길이가 동일한 모두 0으로 구성된 UII를 의미한다.

단계 (5): 리더는 세션 키 생성에 사용되는 리더 측 랜덤넘버(RNint)를 태그에게 전달

함과 동시에 태그의 SecParam, KI 및 세션 키 생성에 사용되는 태그 측 랜덤넘버

(RNtag)를 요청하기 위하여 Sec_ACK 명령을 전송한다.

단계 (6): 태그는 내부적으로 RNtag를 생성하고, 생성된 RNtag와 수신된 RNint를 사용

하여 세션 키를 생성한다. 그리고, Sec_ACK에 대한 응답으로 SecParam, KI, RNtag를 회

신한다.

단계 (7): 리더는 내부적으로 RNint와 RNtag를 사용하여 세션 키를 생성한다. 그리고,

UII를 요청하기 위하여 ACK 명령을 전송한다.

단계 (8): 단계(8) 이후부터는 전송 메시지의 페이로드는 암호화되어 전송된다. 태그는

PC, XPC, UII를 현재의 세션 키로 암호화하여 회신한다.

단계 (9): 리더는 PC, XPC, UII를 복원한 후, 세션 키 생성에 사용된 KI 및 AESKey가

현 단계에서 복원한 UII와 연관성이 있는지 자신의 데이터베이스를 참조하여 검증한다.

만일, 복원된 UII와 관련이 없는 KI 및 AESKey가 사용되었다면 인증 실패로 처리한다.

그리고 리더는 상호 인증을 위하여 Challenge에 해당하는 16 비트 랜덤넘버(CHint)를 포

함한 Sec_ReqRN 명령을 전송한다. 이 때 RN16도 암호화하여 전송하는데, 태그에서

RN16을 복호화하여 확인이 되면 태그는 리더 인증을 성공한 것으로 본다.


TTAK.KO-12.0091/R1 １７

단계 (10): 태그는 CHint를 복호화한 후 이를 다시 암호화하고, 이 값과 새로운 16 비

트 랜덤넘버(Handle)를 회신한다. CHint를 복호화한 후에 다시 암호화하더라도 동일한

암호문 형태를 가지지 않는다. 이는 4.2절의 암호화 방식에서 메시지 암호화는 스트림

암호화 방식처럼 동작하도록 구성하였기 때문이다. 리더에서는 태그가 암호화하여 보낸

CHint를 복호화하여 확인이 되면 태그 인증을 성공한 것으로 본다.

여기까지 정상적으로 진행되었다면 이는 태그와 리더의 상호 인증이 완료된 것이다.

이 후의 단계 (11)과 단계 (12)의 명령/응답은 태그의 메모리를 읽고 쓰기 위한 명령이

될 수 있으며, 주고받는 데이터가 암호화되어 전송되기 때문에 데이터 보호가 가능한 상

황이다.

6.2. 태그 인증 프로토콜

태그 인증 프로토콜 절차는 (그림 6-2)와 같다. 본 프로토콜에서는 태그는 내부에 마

스터 키를 저장하고 있다고 가정한다. 그러나 리더는 마스터 키를 알지 못하며, 오직 인

증서버만이 태그의 마스터 키 정보를 가지고 있다고 가정한다. 태그와 리더, 그리고 인증

서버는 다음과 같은 절차에 따라 태그 인증 프로토콜을 수행한다.


TTAK.KO-12.0091/R1 １８

태그리더

Query

RN16

ACK(RN16)

(1)

(3)

(2)

(4)

Rep(Handle)

PC, XPC, UII

Req_RN(RN16)

Req_Auth(RNint, CHint, Handle)

(8)

Rep(CHtag, Auth_Data)

(12) Calculating Auth_Data

(=EK(CHint CHtag))

(7)

(13)

(12)

(14)

1. Generating session key using RNint and RNtag

2. Decrypting CHtag

3. Calculating Auth_Data (=EK(CHint CHtag))

4. Comparing Auth_Data

서버

Req_Verify(UII, SecParam, RNint,

RNtag, CHint, CHtag, Auth_Data)

Rep(UII, result(Yes or No)) (14)

(9)

: Ciphertext

: Plaintext

Read(AddrSecParam, Handle)

(5)

SecParam, Handle

(6)

Select(0)

(10)RNtag

Get_Auth (Handle)(11)

If Yes, Authentication of tag

(10) Generating session key

using RNint and RNtag

(그림 6-2) 태그 인증 프로토콜

단계 (0) ~ 단계(6): 기존의 ISO/IEC 18000-6 Type C 표준의 inventory 동작과 동일하

다. 세분화하여 설명하면, (0) Select로 태그 그룹을 선택하고, (1) 리더가 태그에게 쿼리

메시지를 전송한다. Query, Query_Adjust, Query_Rep 등은 ISO/IEC 18000-6 Type C에

정의되어 있는 명령이다. 쿼리 메시지를 받은 태그는 (2) 랜덤넘버를 회신한다. 리더는

(3) ACK 명령을 전송하고, 태그에 이에 대한 응답으로써 PC, XPC 및 UII를 평문으로 전

달한다. 그리고, 리더는 (5) Req_RN 명령을 보내며, 이에 대한 응답으로 태그는 (6)

Handle을 응답한다. 이 후부터는 Handle을 보낸 태그와 peer-to-peer 통신이 시작된다.

단계 (7): 본 프로토콜을 따른 리더는 태그의 SecParam을 얻기 위하여 SecParam이

위치한 메모리 주소를 지정하여 Read 명령을 전송한다. 이 때, 리더는 마스터 키가 없으

므로 세션 키를 생성할 수 없어서 모든 명령을 평문으로 전송한다.


TTAK.KO-12.0091/R1 １９

단계 (8): 태그는 Read 명령에 대한 응답으로 SecParam을 회신한다.

단계 (9): 리더는 태그 인증을 위한 인증 데이터를 요청하기 위하여 Req_Auth 명령을

전송한다. Req_Auth 명령은 세션 키 생성에 사용되는 리더의 RNint, Challenge에 해당하

는 CHint를 포함하며, 이들은 평문으로 전송된다.

단계 (10): 태그는 내부적으로 세션 키 생성에 사용되는 태그의 RNtag를 생성하고, 수

신된 RNint와 RNtag를 사용하여 세션 키를 생성한다. 태그는 RNtag를 리더에게 응답한

다.

단계 (11): 리더는 태그 인증을 위한 인증 데이터를 가져오기 위하여 Get_Auth 명령을

전송한다.

단계 (12): 태그는 태그 인증에 사용되는 랜덤넘버(CHtag) 및 Auth_Data를 회신한다.

페이로드에 해당하는 CHtag와 Auth_Data는 암호화된 값이다. Auth_Data는 CHint와

CHtag를 XOR 한 후 이 값을 암호화한 것이다.

단계 (13): Auth_data까지 수신한 리더는 이제 태그와의 통신을 끝내고 인증서버와의

통신을 통해 태그가 보내온 값들을 검증한다. 즉, 리더는 인증서버에게 Req_Verify 메시

지를 보내는데, 파라미터로는 태그의 UII, SecParam, RNint, RNtag, CHint, 그리고 단계

(12)에서 받은 암호화된 CHtag와 Auth_Data를 모두 포함하여 전송한다. 이 때, 리더와

인증서버 사이의 통신은 안전한 채널을 통해 수행된다고 가정한다.

단계 (14): 인증서버는 UII와 관련된 마스터 키를 검색하여 찾고, RNint와 RNtag 및 마

스터 키로부터 세션 키를 유도한다. 인증서버가 자신의 데이터베이스에서 찾은 키 인덱

스와 수신된 SecParam의 키 인덱스가 일치하지 않는다면 곧바로 인증 실패로 처리한다.

일치하면 먼저 CHtag를 복호화하여 구하고, CHint와 CHtag를 XOR하고 세션 키를 사용


TTAK.KO-12.0091/R1 ２０

하여 이를 암호화하여 Auth_Data를 구한다. 인증서버가 자체적으로 구한 Auth_Data 값

과 리더로부터 수신한 Auth_Data 값을 비교하여 동일하면 인증 성공, 동일하지 않으면

인증 실패로 판단하여 그 결과를 리더에게 회신한다.


TTAK.KO-12.0091/R1 ２１

부 록 Ⅰ

보안성 분석 (Informative)

Ⅰ.1. 보안성 분석의 목적

본 부록 Ⅰ의 목적은 본 표준 [수동형 RFID 보안태그와 리더의 인증 및 데이터 보호

프로토콜]에 정의된 보안 프로토콜에 대한 보안성을 설명하기 위함이다.

Ⅰ.2. [6.1. 상호 인증 및 데이터 보호 프로토콜] 보안성 분석

본 표준의 6.1절에서 설명된 “상호 인증 및 데이터 보호 프로토콜”(이하 프로토콜1 이

라 칭함)의 사전 가정은 다음과 같다.

(1) UII는 일반적으로 국제표준 또는 특정 형식을 가지고 있으므로, UII 노출 시 제조사,

물품 유형 등이 예측될 수 있다. 따라서 UII 노출을 방지해야 할 필요성이 있는 곳에

서는 UII를 감추어야 하는데, 프로토콜1의 가장 큰 목적이 임의의 리더로부터 UII를

감추는 것이다.

(2) 태그와 리더는 마스터 키를 서로 알고 있다고 가정한다. 키 관리 기술은 본 표준의

영역이 아니다.

(3) 리더는 각 UII에 대해 해당 UII와 관련된 마스터 키 및 키 인덱스를 데이터베이스화

하여 관리하고 있다고 가정한다.

(4) 프로토콜1이 사용될 것으로 예상되는 환경은 태그가 부착된 물품이 특정 개인 또는

기업에 소유되는 상황으로써, 해당 개인 또는 기업의 리더는 태그의 데이터뿐만 아

니라 UII도 감추고 싶어하는 환경을 가정한다.

상호 인증 및 데이터 보호 프로토콜 절차의 자세한 설명은 다음과 같다.


TTAK.KO-12.0091/R1 ２２

단계 (0) ~ 단계(3): 기존의 ISO/IEC 18000-6 Type C 표준의 동작과 동일하다. 단계

(3)의 ACK 명령은 태그에게 UII(Unique Item Identification)를 요청하는 명령이다. 세분화

하여 설명하면, (0) Select로 태그 그룹을 선택하고, (1) 리더가 태그에게 쿼리 메시지를

전송한다. Query, Query_Adjust, Query_Rep 등은 ISO/IEC 18000-6 Type C에 정의되어

있는 명령이다. 쿼리 메시지를 받은 태그는 (2) 랜덤넘버(RN16)를 회신한다. RN16를 받

은 리더는 (3) ACK 메시지를 전송한다.

기존 18000-6C inventory 과정의 일부임

단계 (4): 본 프로토콜을 따르는 태그는 ACK 명령에 대한 응답으로 PC(Protocol

Control), XPC(eXtended Protocol Control), 그리고 Void UII를 회신한다. 여기서 Void UII

는 진짜 UII와 길이가 동일한 모두 0으로 구성된 UII를 의미한다.

기존의 18000-6C 태그는 이 단계에서 PC, XPC 및 UII를 평문으로 응답하지만, 본

프로토콜1에서는 UII 진짜 값 대신 Void UII (즉, 모두 0 값의 UII)를 응답함. 이는 보안

기능을 가진 리더가 아닌 기존 리더와의 호환성을 위한 것으로서, 기존 리더는 Void UII

를 실제 UII로 인식하기 때문에 본 프로토콜1을 따르는 태그는 기존 리더에게는 진짜 UII

를 노출시키지 않는 효과를 얻을 수 있다.

단계 (5): 리더는 세션 키 생성에 사용되는 리더 측 랜덤넘버(RNint)를 태그에게 전달

함과 동시에 태그의 SecParam, KI 및 세션 키 생성에 사용되는 태그 측 랜덤넘버

(RNtag)를 요청하기 위하여 Sec_ACK 명령을 전송한다.

본 프로토콜 1을 위해서 정의한 리더의 명령이며, RNint 전달의 기능 및 SecParam,

KI, RNtag를 요청하는 기능을 가짐.

단계 (6): 태그는 내부적으로 RNtag를 생성하고, 생성된 RNtag와 수신된 RNint를 사용

하여 세션 키를 생성한다. 그리고, Sec_ACK에 대한 응답으로 SecParam, KI, RNtag를 회

신한다.


TTAK.KO-12.0091/R1 ２３

태그는 이 단계에서 세션 키를 유도하고 대기함. 이 단계에서는 매 세션마다 새로

운 태그의 랜덤넘버(RNtag) 및 리더의 랜덤넘버(RNint)를 사용하여 세션 키를 생성하기

때문에 키 신선도(freshness) 조건이 만족됨

단계 (7): 리더는 내부적으로 RNint와 RNtag를 사용하여 세션 키를 생성한다. 그리고,

UII를 요청하기 위하여 ACK 명령을 전송한다.

리더는 이 단계에서 세션 키를 유도하고 대기함. 이 단계에서는 매 세션마다 새로

운 태그의 랜덤넘버(RNtag) 및 리더의 랜덤넘버(RNint)를 사용하여 세션 키를 생성하기

때문에 키 신선도 조건이 만족됨

단계 (8): 단계(8) 이후부터는 전송 메시지의 페이로드는 암호화되어 전송된다. 태그는

PC, XPC, UII를 현재의 세션 키로 암호화하여 회신한다.

여기서부터는 데이터들이 암호화되어 통신됨. 즉, 이 단계에서 태그가 진짜 UII를

전달하며, 그 값은 암호화되어 있음. 따라서, 리더가 정확한 마스터 키를 가지고 세션 키

를 유도했을 경우에만 해당 UII를 복원할 수 있음.

단계 (9): 리더는 PC, XPC, UII를 복원한 후, 세션 키 생성에 사용된 KI 및 AESKey가

현 단계에서 복원한 UII와 연관성이 있는지 자신의 데이터베이스를 참조하여 검증한다.

만일, 복원된 UII와 관련이 없는 KI 및 AESKey가 사용되었다면 인증 실패로 처리한다.

그리고 리더는 상호 인증을 위하여 Challenge에 해당하는 16 비트 랜덤넘버(CHint)를 포

함한 Sec_ReqRN 명령을 전송한다. 이 때 RN16도 암호화하여 전송하는데, 태그에서

RN16을 복호화하여 확인이 되면 태그는 리더 인증을 성공한 것으로 본다.

공격자가 고의적 또는 우연히 하나의 태그에 대한 마스터 키와 키 인덱스를 획득하

게 되면 임의의 UII로 인증을 시도할 수 있는데, 리더에서 UII와 관련된 마스터 키 및 키

인덱스를 유지하기 때문에 임의의 UII 인증 시도를 차단할 수 있음. 그리고 이 단계에서

는 리더는 2가지 효과를 추구함. 첫째는 Handle로 사용하던 RN16을 암호화하여 태그에

게 전달함으로써 태그가 이를 복호화하여 RN16을 확인하도록 하여 리더 자신을 인증시


TTAK.KO-12.0091/R1 ２４

키는 것임. 둘째는 태그에게 Challenge 16비트 랜덤넘버를 전달하고 태그로부터 암호화

된 Challenge가 제대로 오기를 기다리는 것임. 이는 태그를 인증하기 위함임.

단계 (10): 태그는 CHint를 복호화한 후 이를 다시 암호화하고, 이 값과 새로운 16 비

트 랜덤넘버(Handle)를 회신한다. CHint를 복호화한 후에 다시 암호화하더라도 동일한

암호문 형태를 가지지 않는다. 이는 4.2절의 암호화 방식에서 메시지 암호화는 스트림

암호화 방식처럼 동작하도록 구성하였기 때문이다. 리더에서는 태그가 암호화하여 보낸

CHint를 복호화하여 확인이 되면 태그 인증을 성공한 것으로 본다.

리더는 태그로부터 암호화되어 전달되어 온 CHint를 복호화하여 확인함.

위와 같은 절차를 통해 제공할 수 있는 보안 서비스는 다음과 같다.

(1) 상호 인증: 리더는 태그가 생성한 RN16을 암호화하여 회신하고, 태그는 리더가 생성

한 CHint를 암호화하여 회신하기 때문에 각각 이를 복호화하여 확인할 수 있다면,

상대가 정확한 세션 키를 사용하고 있다고 볼 수 있다. 이는 정확한 마스터 키로부

터 세션 키를 유도한 것이므로 서로 마스터 키를 공유한 정당한 태그와 리더라고 인

증할 수 있다.

(2) 데이터 기밀성: 중요 정보로 취급할 수 있는 UII를 암호화하여 전달하며, 이후에 사

용자 메모리 영역의 데이터 읽기와 쓰기 등의 명령/응답은 암호화 통신이 수행된다.

(3) Spoofing 공격 탐지: 프로토콜1의 절차 중 단계 (5)와 단계 (6)는 매 세션마다 다르

게 생성되는 RNint와 RNtag를 주고 받는 절차이다. RNint와 RNtag는 세션 키 생성

에 사용되는 IV(Initial Vector) 역할을 하기 때문에 매 세션마다 다르게 사용된다는

것은 세션 키의 신선도를 보장할 수 있음을 의미한다. 이는 악의적인 도청자의

replay에 의한 spoofing 공격을 탐지해 낼 수 있는 특성을 가진다.

(4) 제품정보 노출 방지: 일반적인 태그는 고유의 아이디로서 태그 자체적인 아이디(TID)

및 부착되는 물품과 관련된 유일 아이디(UII)를 가진다. 만일 특정 개인 또는 기업이

UII를 사용할 때, UII가 손쉽게 노출되는 것은 임의의 리더가 UII 를 읽음으로써 UII


TTAK.KO-12.0091/R1 ２５

포맷 규칙에 따라 제품정보를 파악할 수 있다. 그러나, 프로토콜1은 세션 키를 생성

할 수 있는 정상적인 리더를 제외한 임의의 리더에 대해서는 실제 UII를 감추기 때

문에 제품정보 노출을 막을 수 있다. 이러한 특징은 사용자 프라이버시 보호와도 일

맥상통하다고 볼 수 있다.

Ⅰ.3. [6.2. 태그 인증 프로토콜] 보안성 분석

본 표준의 6.2절에서 설명된 “태그 인증 프로토콜”(이하 프로토콜2라 칭함)의 사전 가

정은 다음과 같다.

(1) 프로토콜2에서는 리더의 inventory 과정은 기존 18000-6C와 동일하다. 즉 모든

리더에게 태그는 자신의 UII를 평문으로 전달한다.

(2) 마스터 키는 태그 내부에 저장되어 있으며, 리더는 마스터 키를 알지 못한다고

가정한다. 마스터 키의 사용은 오직 태그가 자신을 인증시키는 데만 사용한다.

(3) 인증서버가 별도로 존재한다고 가정하며, 인증서버는 태그의 마스터 키를 알고

있다고 가정한다.

(4) 인증서버는 각 UII에 대해 해당 UII와 관련된 마스터 키 및 키 인덱스를 데이터

베이스화하여 관리하고 있다고 가정한다.

(5) 프로토콜2가 사용될 것으로 예상되는 대표적인 장소는 정육점과 같은 상점이다.

이러한 환경에서는 상점의 리더는 인증서버와는 서로 안전한 통신이 된다고 가정한

다. 그러나 상점의 리더가 태그(정육점의 경우는 쇠고기 포장에 부착된 태그)의 마스

터 키를 알게 된다면 이를 악용할 수 있는 여지가 있기 때문에 원천적으로 이를 막

기 위해서는 상점의 리더가 마스터 키를 몰라야 한다. 그렇지만 소비자는 해당 태그

가 정상적인 태그인지는 확인해야 하므로 상점의 리더 또는 소비자의 휴대 리더를

통해 태그를 인증해야 한다. 즉, 프로토콜2의 가장 큰 목적은 임의의 리더가 인증서

버로부터 태그의 인증여부를 확인 받을 수 있도록 하는 것이다.


TTAK.KO-12.0091/R1 ２６

태그 인증 프로토콜 절차의 자세한 설명은 다음과 같다.

단계 (0) ~ 단계(6): 기존의 ISO/IEC 18000-6 Type C 표준의 inventory 동작과 동일하

다. 세분화하여 설명하면, (0) Select로 태그 그룹을 선택하고, (1) 리더가 태그에게 쿼리

메시지를 전송한다. Query, Query_Adjust, Query_Rep 등은 ISO/IEC 18000-6 Type C에

정의되어 있는 명령이다. 쿼리 메시지를 받은 태그는 (2) 랜덤넘버를 회신한다. 리더는

(3) ACK 명령을 전송하고, 태그에 이에 대한 응답으로써 PC, XPC 및 UII를 평문으로 전

달한다. 그리고, 리더는 (5) Req_RN 명령을 보내며, 이에 대한 응답으로 태그는 (6)

Handle을 응답한다. 이 후부터는 Handle을 보낸 태그와 peer-to-peer 통신이 시작된다.

기존 18000-6C inventory 과정과 동일함.

단계 (7): 본 프로토콜을 따른 리더는 태그의 SecParam을 얻기 위하여 SecParam이

위치한 메모리 주소를 지정하여 Read 명령을 전송한다. 이 때, 리더는 마스터 키가 없으

므로 세션 키를 생성할 수 없어서 모든 명령을 평문으로 전송한다.

리더의 명령이며, 평문 전송임.

단계 (8): 태그는 Read 명령에 대한 응답으로 SecParam을 회신한다.

태그의 응답이며, 평문 전송임.

단계 (9): 리더는 태그 인증을 위한 인증 데이터를 요청하기 위하여 Req_Auth 명령을

전송한다. Req_Auth 명령은 세션 키 생성에 사용되는 리더의 RNint, Challenge에 해당하

는 CHint를 포함하며, 이들은 평문으로 전송된다.

이 단계에서 리더는 세션 키 생성에 사용되는 RNint와 Challenge에 해당하는 CHint

를 평문으로 전송함.

단계 (10): 태그는 내부적으로 세션 키 생성에 사용되는 태그의 RNtag를 생성하고, 수

신된 RNint와 RNtag를 사용하여 세션 키를 생성한다. 태그는 RNtag를 리더에게 응답한


TTAK.KO-12.0091/R1 ２７

다.

태그는 이 단계에서 세션 키를 유도하고 대기함. 이 단계에서는 매 세션마다 새로

운 태그의 RNtag 및 리더의 RNint를 사용하여 세션 키를 생성하기 때문에 키 신선도 조

건이 만족됨. Req_Auth에 대한 응답으로 곧바로 암호화된 Auth_Data를 보내지 못하고

RNtag만을 보내면서 Get_Auth를 다시 기다리는 이유는 그 사이에 AES 모듈을 사용하여

세션 키를 생성하는 시간을 벌기 위함임.

단계 (11): 리더는 태그 인증을 위한 인증 데이터를 가져오기 위하여 Get_Auth 명령을

전송한다.

암호화된 Auth_Data를 얻기 위한 리더의 명령임.

단계 (12): 태그는 태그 인증에 사용되는 랜덤넘버(CHtag) 및 Auth_Data를 회신한다.

페이로드에 해당하는 CHtag와 Auth_Data는 암호화된 값이다. Auth_Data는 CHint와

CHtag를 XOR 한 후 이 값을 암호화한 것이다.

태그는 인증용 데이터로서 리더로부터 수신한 CHint와 태그 자신이 생성한 CHtag

를 XOR 한 값을 사용함. 그리고, 태그는 CHtag와 인증용 데이터를 암호화하여 전달함.

단계 (13): Auth_data까지 수신한 리더는 이제 태그와의 통신을 끝내고 인증서버와의

통신을 통해 태그가 보내온 값들을 검증한다. 즉, 리더는 인증서버에게 Req_Verify 메시

지를 보내는데, 파라미터로는 태그의 UII, SecParam, RNint, RNtag, CHint, 그리고 단계

(12)에서 받은 암호화된 CHtag와 Auth_Data를 모두 포함하여 전송한다. 이 때, 리더와

인증서버 사이의 통신은 안전한 채널을 통해 수행된다고 가정한다.

리더는 마스터 키가 없기 때문에 태그와의 통신을 통해 얻은 정보를 인증서버로 전

달함. 리더와 인증서버와의 통신은 일종의 웹서버 접속으로 볼 수 있음. 따라서 리더는

상점의 리더 또는 소비자의 휴대 리더(예를 들면, 휴대폰에 장착된 리더)가 될 수 있음.


TTAK.KO-12.0091/R1 ２８

단계 (14): 인증서버는 UII와 관련된 마스터 키를 검색하여 찾고, RNint와 RNtag 및 마

스터 키로부터 세션 키를 유도한다. 인증서버가 자신의 데이터베이스에서 찾은 키 인덱

스와 수신된 SecParam의 키 인덱스가 일치하지 않는다면 곧바로 인증 실패로 처리한다.

일치하면 먼저 CHtag를 복호화하여 구하고, CHint와 CHtag를 XOR하고 세션 키를 사용

하여 이를 암호화하여 Auth_Data를 구한다. 인증서버가 자체적으로 구한 Auth_Data 값

과 리더로부터 수신한 Auth_Data 값을 비교하여 동일하면 인증 성공, 동일하지 않으면

인증 실패로 판단하여 그 결과를 리더에게 회신한다.

인증서버는 주어진 정보에 기반하여 결과만을 회신함. 공격자가 고의적 또는 우연

히 하나의 태그에 대한 마스터 키와 키 인덱스를 획득하게 되면 임의의 UII로 인증을 시

도할 수 있는데, 인증서버에서 UII와 관련된 마스터 키 및 키 인덱스를 유지하기 때문에

임의의 UII 인증 시도를 차단할 수 있음.

위와 같은 절차를 통해 제공할 수 있는 보안 서비스는 다음과 같다.

(1) 태그 인증: 프로토콜2는 모든 리더에게 UII를 평문으로 제공한다. 즉, 리더 인증을

요구하지는 않는 응용에서 사용 가능하다. 그러나 태그 인증은 중요하게 고려하고

있다. 태그는 리더가 생성하여 전달해 준 CHint를 포함하여 인증용 데이터를 생성한

후 이를 암호화하여 회신하기 때문에 인증서버에서 확인한 값이 정확한 값이라면 태

그는 정확한 세션 키를 사용하고 있다고 볼 수 있다. 이는 정확한 마스터 키로부터

세션 키를 유도한 것이므로 태그가 가진 마스터 키는 인증서버가 가진 마스터 키와

동일하다고 보고 정당한 태그라고 인증할 수 있다.

(2) Spoofing 공격 탐지: 프로토콜2의 절차 중 단계 (9)와 단계 (10)에서 매 세션마다 다

르게 생성되는 RNint와 RNtag를 주고 받을 수 있다. RNint와 RNtag는 세션 키 생성

에 사용되는 IV(Initial Vector) 역할을 하기 때문에 매 세션마다 다르게 사용된다는

것은 세션 키의 신선도를 보장할 수 있음을 의미한다. 이는 악의적인 도청자의

replay에 의한 spoofing 공격을 탐지해 낼 수 있는 특성을 가진다.


TTAK.KO-12.0091/R1 ２９

(참고로, 프로토콜2에서는 UII 자체를 공개하고 있으며 리더가 마스터 키를 가지고 있

지 않기 때문에 제품정보 노출 방지(사용자 프라이버시 보호 측면)와 데이터 암/복호화

(데이터 기밀성 측면) 보안 서비스는 제공하지 못한다. 즉 프로토콜2의 주요 관심대상은

태그 인증일 뿐이다.)

Ⅰ.4. 알려진 취약점

본 표준에 정의된 보안 프로토콜의 알려진 취약점은 다음과 같다.

첫째, 6.1절 상호 인증 및 데이터 보호 프로토콜에서는 세션 키 비트 스트림의 일부가

노출될 수 있다. 단계(8)의 PC, XPC와 단계(9)의 RN16은 암호화하여 전송하게 되는데,

이 데이터들은 이전 단계에서 평문으로 전송되고 있기 때문에 단계(8)과 단계(9)의 암호

화된 PC, XPC, RN16과 평문 PC, XPC, RN16이 도청될 경우, 프로토콜1의 암/복호화 방

법이 본 표준 4.2절의 (그림 4-4)와 같으므로 2개의 데이터를 그대로 XOR하면 키 비트

스트림 중 일부가 노출될 수 있다. 그러나 이후에 암호화되는 데이터는 shift된 곳의 키

비트가 사용되기 때문에 노출된 일부 키 비트로 인한 추가적인 데이터 노출의 위험은 없

다. 본 표준은 RN16 암호화 및 복호화 동작을 리더 인증 수단으로 사용하고 있으며, 또

한 태그에서 세션 키가 설립된 이후에는 모든 응답의 페이로드는 암호화시켜 응답하는

구현의 효율성을 고려하여 프로토콜1을 설계하였다.

둘째, 6.1절과 6.2절의 프로토콜에서, 랜덤넘버 및 Challenge로 사용되는 정보들은 16

비트로 구성되어 있다. 전사 공격(brute force attack)을 수행할 경우 216의 안전성이라고

볼 수 있다.

셋째, 공격자가 고의적 또는 우연히 하나의 태그에 대한 마스터 키와 키 인덱스를 획

득하게 되면 정상적인 리더를 상대로 임의의 UII를 사용하여 태그 인증을 시도할 수 있

다. 만일 태그 인증을 수행하는 리더 또는 인증서버에서 태그의 UII와 관련된 마스터 키


TTAK.KO-12.0091/R1 ３０

및 키 인덱스를 데이터베이스화하여 관리하지 않는다면 임의의 UII에 대한 태그 인증이

성공할 수 있을 것이다. 그러나 본 표준의 프로토콜1과 프로토콜2의 예상 활용환경을 고

려하면 다음과 같은 상황이 된다.

프로토콜1의 경우, 프로토콜1의 가장 큰 목적은 UII 자체도 감추는 것이다. 이는 보안

서비스 측면에서 사용자 프라이버시 보호와 제품정보 노출 방지 효과를 가져올 수 있다.

특히 개인화된 제품인 경우는 키 관리가 전적으로 개인 리더(예를 들면, 휴대폰)에서 처

리된다. 만약 공격자가 내 소유의 물품을 취득하여 하나의 키와 그에 해당하는 키 인덱

스를 알아낸다고 가정하면 그 공격자가 얻을 수 있는 효과는 임의의 UII로 인증을 받을

수 있는 것이다. 하지만 공격자의 인증 성공은 본 표준의 프로토콜1이 추구하는 사용자

프라이버시 보호와 제품정보 노출 방지에는 영향을 주지는 않는다. 또한, 리더에서 세션

키 생성에 사용된 마스터 키 및 키 인덱스가 수신된 UII와 연관성이 있는지 자신의 데이

터베이스를 참조하여 검증하게 되면 이러한 태그 인증 시도에 대해 오류로 처리할 수 있

다.

프로토콜2의 경우, 프로토콜2도 UII와 마스터 키가 서로 연관되어 있는 환경을 고려한

다. 즉 인증서버는 UII를 수신하여 그 UII와 관련된 마스터 키와 키 인덱스를 데이터베이

스로 관리하고 있는 것이다. 따라서 임의의 UII가 공격자에게 노출된 마스터 키 및 키 인

덱스와 연결이 되지 않는다면 인증서버에서 이를 확인하여 오류로 처리할 수 있다.


TTAK.KO-12.0091/R1 ３１

부 록 Ⅱ

키 공유 방법 (Informative)

보안 프로토콜이 암호 알고리즘을 사용해야 한다면 반드시 키 공유가 선행되어야 한다.

본 표준은 수동형 RFID 태그가 보안 프로토콜 수행 주체가 되기 때문에 그에 맞는 키

공유 방법이 고려되어야 한다. 즉, 구현 가능성을 염두에 두어야 하고 수동형 RFID 태그

가 어떻게 사용되고 어떻게 유통되는지 또는 리더는 어떠한 상황에서 수동형 RFID 태그

에 접근하는지 등이 고려되어야 한다.

Ⅱ.1. [6.1. 상호 인증 및 데이터 보호 프로토콜] 키 공유 방법

이 프로토콜이 동작되는 상황은 태그가 부착된 제품을 특정 개인이 구입하여 자신의

소유물로 확보하는 경우를 예상할 수 있다. 이러한 경우에 리더는 사용자의 휴대 단말(예

를 들면, 휴대폰)이 될 수 있다.

따라서, 태그의 마스터 키를 상점의 단말기가 알고 있고 사용자가 제품을 구입하여 계

산할 때 상점의 단말기가 사용자의 휴대 단말에 마스터 키를 전달할 수 있다면 리더와

태그는 마스터 키 공유가 가능하다. 이 때 상점의 단말기는 사용자 휴대 단말에 단문 메

시지 서비스를 이용하여 마스터 키를 전달하는 방법을 사용할 수 있으며 이후부터는 사

용자가 해당 마스터 키를 입력하여 태그와 보안 프로토콜을 수행할 수 있다.

또한, 사용자가 직접 키 인덱스를 지정할 수도 있는데 이러한 키 관련 정보는 모두 사

용자의 휴대 단말 내부에서 관리되며, 태그는 사용자의 소유물에 부착되어 있는 환경에

서 운용될 것이다.

Ⅱ.2. [6.2. 태그 인증 프로토콜] 키 공유 방법

이 프로토콜의 참여 주체는 태그, 리더 및 인증서버이며 키 공유 대상은 태그와 인증

서버이다. 인증서버가 태그의 마스터 키와 키 인덱스를 데이터베이스로 관리한다면 태그


TTAK.KO-12.0091/R1 ３２

는 자신의 UII를 제공하는 것만으로 키 공유가 가능하다. 이러한 경우는 당연히 태그가

부착된 제품을 유통시키는 서비스 제공업자가 제품 유통 이전에 태그에 마스터 키를 입

력시키고 이에 대한 정보를 인증서버에 저장하는 작업을 선행해야 한다.


TTAK.KO-12.0091/R1 ３３

부 록 Ⅲ

암/복호화 pseudo code (Informative)

다음의 예제는 리더에서 32 비트 데이터를 암호화하여 보내고, 태그로부터 32 비트 암

호문을 수신한 후 다시 32 비트 데이터를 암호화하여 보내는 동작을 가정한 것이다.

{

//32 비트 데이터 송신(암호화)

get session_key[0:127];

get plain_data_1[0:31];

generate encrypted_data_1[0:31] by XORing the plain_data_1[0:31] and

the session_key[0:31];

create command_code_1[0:15];

add command_code_1[0:15] in front of the encrypted_data_1;

calculate CRC16_1[0:15] over the first command_code_1 bit to the last

encrytpted_data_1 bit;

add CRC16_1[0:15] at the back of the encrypted_data_1;

send (command_code_1 || encrypted_data_1 || CRC16_1) to tag;

//32 비트 데이터 수신 (복호화)

receive encrypted_data_2[0:31] and CRC16_2[0:15];

verify CRC16_2[0:15];

(if CRC16_2 is invalid, then ignore this message)

recover decrtyped_data_2[0:31] by XORing the encrypted_data_2[0:31]

and the session_key[32:63];


TTAK.KO-12.0091/R1 ３４

//추가적인 32 비트 데이터 송신(암호화)

get plain_data_3[0:31];

generate encrypted_data_3[0:31] by XORing the plain_data_3[0:31] and

the session_key[64:95];

create command_code_3[0:15];

add command_code_3[0:15] in front of the encrypted_data_3;

calculate CRC16_3[0:15] over the first command_code_3 bit to the last

encrytpted_data_3 bit;

add CRC16_3[0:15] at the back of the encrypted_data_3;

send (command_code_3 || encrypted_data_3 || CRC16_3) to tag;

}


TTAK.KO-12.0091/R1 ３５

표준 작성 공헌자

표준 번호 : TTAK.KO-12.0091/R1

이 표준의 제정개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다.

구분 성명 위원회 및 직위 연락처

(E-mail 등) 소속사

과제 제안 강유성 응용보안 및 평가인증

프로젝트그룹 위원

042-860-5960

[email protected] ETRI

표준 초안 제출 강유성 응용보안 및 평가인증


042-860-5960


표준 초안 검토

및 작성

권혁찬 응용보안 및 평가인증


042-860-5941


주홍일 응용보안 및 평가인증


042-860-5988


이필중 정보보호 기술위원회

부의장

054-279-2232

[email protected] POSTECH

외 PG504 위원

표준안 심의

원유재 정보보호 기술위원회

의장

02-405-5300

[email protected] KISA

서동일 정보보호 기술위원회

부의장

042-860-5611


이필중 정보보호 기술위원회

부의장

054-279-2232

[email protected] POSTECH

외 정보보호 기술위원회

위원

사무국 담당

박정식 팀 장 031-724-0080

[email protected] TTA

오흥룡 과 장 070-7780-0083

[email protected] TTA




(Authentication and Data Protection Protocol

of Passive RFID Security Tag and Reader)

발행인 : 한국정보통신기술협회 회장

발행처 : 한국정보통신기술협회

463-824, 경기도 성남시 분당구 서현동 267-2

Tel : 031-724-0114, Fax : 031-724-0109

발행일 : 2009.12.

t t a s t a n d a r d 1. 표준의 목적 본 표준은 ttai.ko-12.0091 (2008년 12월 19일...

Documents