검색결과
-
[기획-디지털 ID 표준] ⑮산업단체와 포럼 - 오픈ID(OpenID)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.오픈ID(OpenID)는 개인 및 기업의 비영리 국제 표준화 조직으로 OpenID(개방형 표준 및 분산 인증 프로토콜)를 활성화, 홍보, 보호하기 위해 노력하고 있다.오픈ID 코넥트 코어(OpenID Connect Core)는 핵심 OpenID 기능을 정의하고 있다. OpenID 기능은 OAuth 2.0 기반에 구축된 인증과 최종 사용자에 대한 정보를 전달하기 위한 클레임의 사용이다. 추가적인 기술 사양 문서는 검증 가능한 자격 증명 및 검증 가능한 프리젠테이션의 발급을 확장하기 위해 작성됐다. 또한 OpenID Connect 사용에 대한 보안 및 개인 정보 보호 고려 사항에 대해 설명하고 있다.아래는 오픈ID가 발행한 'OpenID Connect Core 1.0 incorporating errata set 1' 목차 내용이다.■ 목차(Table of Contents)1. Introduction1.1. Requirements Notation and Conventions1.2. Terminology1.3. Overview2. ID Token3. Authentication3.1. Authentication using the Authorization Code Flow3.1.1. Authorization Code Flow Steps3.1.2. Authorization Endpoint3.1.2.1. Authentication Request3.1.2.2. Authentication Request Validation3.1.2.3. Authorization Server Authenticates End-User3.1.2.4. Authorization Server Obtains End-User Consent/Authorization3.1.2.5. Successful Authentication Response3.1.2.6. Authentication Error Response3.1.2.7. Authentication Response Validation3.1.3. Token Endpoint3.1.3.1. Token Request3.1.3.2. Token Request Validation3.1.3.3. Successful Token Response3.1.3.4. Token Error Response3.1.3.5. Token Response Validation3.1.3.6. ID Token3.1.3.7. ID Token Validation3.1.3.8. Access Token Validation3.2. Authentication using the Implicit Flow3.2.1. Implicit Flow Steps3.2.2. Authorization Endpoint3.2.2.1. Authentication Request3.2.2.2. Authentication Request Validation3.2.2.3. Authorization Server Authenticates End-User3.2.2.4. Authorization Server Obtains End-User Consent/Authorization3.2.2.5. Successful Authentication Response3.2.2.6. Authentication Error Response3.2.2.7. Redirect URI Fragment Handling3.2.2.8. Authentication Response Validation3.2.2.9. Access Token Validation3.2.2.10. ID Token3.2.2.11. ID Token Validation3.3. Authentication using the Hybrid Flow3.3.1. Hybrid Flow Steps3.3.2. Authorization Endpoint3.3.2.1. Authentication Request3.3.2.2. Authentication Request Validation3.3.2.3. Authorization Server Authenticates End-User3.3.2.4. Authorization Server Obtains End-User Consent/Authorization3.3.2.5. Successful Authentication Response3.3.2.6. Authentication Error Response3.3.2.7. Redirect URI Fragment Handling3.3.2.8. Authentication Response Validation3.3.2.9. Access Token Validation3.3.2.10. Authorization Code Validation3.3.2.11. ID Token3.3.2.12. ID Token Validation3.3.3. Token Endpoint3.3.3.1. Token Request3.3.3.2. Token Request Validation3.3.3.3. Successful Token Response3.3.3.4. Token Error Response3.3.3.5. Token Response Validation3.3.3.6. ID Token3.3.3.7. ID Token Validation3.3.3.8. Access Token3.3.3.9. Access Token Validation4. Initiating Login from a Third Party5. Claims5.1. Standard Claims5.1.1. Address Claim5.1.2. Additional Claims5.2. Claims Languages and Scripts5.3. UserInfo Endpoint5.3.1. UserInfo Request5.3.2. Successful UserInfo Response5.3.3. UserInfo Error Response5.3.4. UserInfo Response Validation5.4. Requesting Claims using Scope Values5.5. Requesting Claims using the "claims" Request Parameter5.5.1. Individual Claims Requests5.5.1.1. Requesting the "acr" Claim5.5.2. Languages and Scripts for Individual Claims5.6. Claim Types5.6.1. Normal Claims5.6.2. Aggregated and Distributed Claims5.6.2.1. Example of Aggregated Claims5.6.2.2. Example of Distributed Claims5.7. Claim Stability and Uniqueness6. Passing Request Parameters as JWTs6.1. Passing a Request Object by Value6.1.1. Request using the "request" Request Parameter6.2. Passing a Request Object by Reference6.2.1. URL Referencing the Request Object6.2.2. Request using the "request_uri" Request Parameter6.2.3. Authorization Server Fetches Request Object6.2.4. "request_uri" Rationale6.3. Validating JWT-Based Requests6.3.1. Encrypted Request Object6.3.2. Signed Request Object6.3.3. Request Parameter Assembly and Validation7. Self-Issued OpenID Provider7.1. Self-Issued OpenID Provider Discovery7.2. Self-Issued OpenID Provider Registration7.2.1. Providing Information with the "registration" Request Parameter7.3. Self-Issued OpenID Provider Request7.4. Self-Issued OpenID Provider Response7.5. Self-Issued ID Token Validation8. Subject Identifier Types8.1. Pairwise Identifier Algorithm9. Client Authentication10. Signatures and Encryption10.1. Signing10.1.1. Rotation of Asymmetric Signing Keys10.2. Encryption10.2.1. Rotation of Asymmetric Encryption Keys11. Offline Access12. Using Refresh Tokens12.1. Refresh Request12.2. Successful Refresh Response12.3. Refresh Error Response13. Serializations13.1. Query String Serialization13.2. Form Serialization13.3. JSON Serialization14. String Operations15. Implementation Considerations15.1. Mandatory to Implement Features for All OpenID Providers15.2. Mandatory to Implement Features for Dynamic OpenID Providers15.3. Discovery and Registration15.4. Mandatory to Implement Features for Relying Parties15.5. Implementation Notes15.5.1. Authorization Code Implementation Notes15.5.2. Nonce Implementation Notes15.5.3. Redirect URI Fragment Handling Implementation Notes15.6. Compatibility Notes15.6.1. Pre-Final IETF Specifications15.6.2. Google "iss" Value15.7. Related Specifications and Implementer's Guides16. Security Considerations16.1. Request Disclosure16.2. Server Masquerading16.3. Token Manufacture/Modification16.4. Access Token Disclosure16.5. Server Response Disclosure16.6. Server Response Repudiation16.7. Request Repudiation16.8. Access Token Redirect16.9. Token Reuse16.10. Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)16.11. Token Substitution16.12. Timing Attack16.13. Other Crypto Related Attacks16.14. Signing and Encryption Order16.15. Issuer Identifier16.16. Implicit Flow Threats16.17. TLS Requirements16.18. Lifetimes of Access Tokens and Refresh Tokens16.19. Symmetric Key Entropy16.20. Need for Signed Requests16.21. Need for Encrypted Requests17. Privacy Considerations17.1. Personally Identifiable Information17.2. Data Access Monitoring17.3. Correlation17.4. Offline Access18. IANA Considerations18.1. JSON Web Token Claims Registration18.1.1. Registry Contents18.2. OAuth Parameters Registration18.2.1. Registry Contents18.3. OAuth Extensions Error Registration18.3.1. Registry Contents19. References19.1. Normative References19.2. Informative ReferencesAppendix A. Authorization ExamplesA.1. Example using response_type=codeA.2. Example using response_type=id_tokenA.3. Example using response_type=id_token tokenA.4. Example using response_type=code id_tokenA.5. Example using response_type=code tokenA.6. Example using response_type=code id_token tokenA.7. RSA Key Used in ExamplesAppendix B. AcknowledgementsAppendix C. Notices§ Authors' Addresses
-
[기획-디지털 ID 표준] ⑭산업단체와 포럼 - 오아시스(OASIS)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.구조화 정보 표준 개발기구(Organization for the Advancement of Structured Information Standards, OASIS)는 공급업체와 사용자의 컨소시엄으로 시작됐다.오늘날 사이버보안(cybersecurity), 블록체인(blockchain), 사물인터넷(internet of things, IoT), 비상 경영(emergency management), 클라우드 컴퓨팅(cloud computing) 등 프로젝트를 발전시키는 대규모 비영리 표준 조직이다.오아시스는 '디지털 서명 서비스 핵심 프로토콜, 요소, 바인딩'과 같은 디지털 서명과 관련된 프로토콜, 프로필 등 기술 사양을 개발해왔다.오아시스는 ISO에 협력하고 있는 조직으로 각 기술위원회(TC) 또는 분과위원회(SC)가 다루는 문제에 대해 기술위원회(TC) 또는 분과위원회(SC)의 업무에 효과적으로 기여하는 조직(A liaisons)이다.기여하고 있는 기술위원회 및 분과위원회는 다음과 같다.▷ISO/IEC JTC 1/SC 6 시스템 간 통신 및 정보 교환▷ISO/IEC JTC 1/SC 34 문서 설명 및 처리 언어▷ISO/IEC JTC 1/SC 38 클라우드 컴퓨팅 및 분산 플랫폼▷ISO/IEC JTC 1/SC 40 IT 서비스 관리 및 IT 거버넌스▷ISO/TC 12 수량 및 단위▷ISO/TC 37 언어 및 용어▷ISO/TC 37/SC 5 번역, 통역 및 관련 기술▷ISO/TC 46/SC 4 기술적 상호 운용성▷ISO/TC 154 상업, 산업 및 행정 분야의 프로세스, 데이터 요소 및 문서▷ISO/TC 184/SC 4 산업 데이터▷ISO/TC 211 지리정보/지리학또한 오아시스는 2005년 10월 21일 Working Draft 34에서 Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0을 발표했다.이후 2019년 12월 11일 'Digital Signature Service Core Protocols, Elements, and Bindings Version 2.0 Committee Specification 02'가 발표됐다.버전 2.0의 목차를 살펴보면 다음과 같다.■ 목차(Table of Contents) 1 Introduction 1.1 IPR Policy 1.2 Terminology 1.2.1 Terms and Definitions 1.2.2 Abbreviated Terms 1.3 Normative References 1.4 Non-Normative References 1.5 Typographical Conventions 1.6 DSS Overview (Non-normative) 2 Design Considerations 2.1 Version 2.0 goal [non-normative] 2.2 Transforming DSS 1.0 into 2.0 2.2.1 Circumventing xs:any 2.2.2 Substituting the mixed Schema Attribute 2.2.3 Introducing the NsPrefixMappingType Component 2.2.4 Imported XML schemes 2.2.5 Syntax variants 2.2.6 JSON Syntax Extensions 2.3 Construction Principles 2.3.1 Multi Syntax approach 2.4 Schema Organization and Namespaces 2.5 DSS Component Overview 2.5.1 Schema Extensions 3 Data Type Models 3.1 Boolean Model 3.2 Integer Model 3.3 String Model 3.4 Binary Data Model 3.5 URI Model 3.6 Unique Identifier Model 3.7 Date and Time Model 3.8 Lang Model 4 Data Structure Models 4.1 Data Structure Models defined in this document 4.1.1 Component NsPrefixMapping 4.1.1.1 NsPrefixMapping – JSON Syntax 4.1.1.2 NsPrefixMapping – XML Syntax 4.2 Data Structure Models defined in this document 4.2.1 Component InternationalString 4.2.1.1 InternationalString – JSON Syntax 4.2.1.2 InternationalString – XML Syntax 4.2.2 Component DigestInfo 4.2.2.1 DigestInfo – JSON Syntax 4.2.2.2 DigestInfo – XML Syntax 4.2.3 Component AttachmentReference 4.2.3.1 AttachmentReference – JSON Syntax 4.2.3.2 AttachmentReference – XML Syntax 4.2.4 Component Any 4.2.4.1 Any – JSON Syntax 4.2.4.2 Any – XML Syntax 4.2.5 Component Base64Data 4.2.5.1 Base64Data – JSON Syntax 4.2.5.2 Base64Data – XML Syntax 4.2.6 Component SignaturePtr 4.2.6.1 SignaturePtr – JSON Syntax 4.2.6.2 SignaturePtr – XML Syntax 4.2.7 Component Result 4.2.7.1 Result – JSON Syntax 4.2.7.2 Result – XML Syntax 4.2.8 Component OptionalInputs 4.2.8.1 OptionalInputs – JSON Syntax 4.2.8.2 OptionalInputs – XML Syntax 4.2.9 Component OptionalOutputs 4.2.9.1 OptionalOutputs – JSON Syntax 4.2.9.2 OptionalOutputs – XML Syntax 4.2.10 Component RequestBase 4.2.10.1 RequestBase – JSON Syntax 4.2.10.2 RequestBase – XML Syntax 4.2.11 Component ResponseBase 4.2.11.1 ResponseBase – JSON Syntax 4.2.11.2 ResponseBase – XML Syntax 4.3 Operation requests and responses 4.3.1 Component SignRequest 4.3.1.1 SignRequest – JSON Syntax 4.3.1.2 SignRequest – XML Syntax 4.3.2 Component SignResponse 4.3.2.1 SignResponse – JSON Syntax 4.3.2.2 SignResponse – XML Syntax 4.3.3 Component VerifyRequest 4.3.3.1 VerifyRequest – JSON Syntax 4.3.3.2 VerifyRequest – XML Syntax 4.3.4 Component VerifyResponse 4.3.4.1 VerifyResponse – JSON Syntax 4.3.4.2 VerifyResponse – XML Syntax 4.3.5 Component PendingRequest 4.3.5.1 PendingRequest – JSON Syntax 4.3.5.2 PendingRequest – XML Syntax 4.4 Optional data structures defined in this document 4.4.1 Component RequestID 4.4.1.1 RequestID – JSON Syntax 4.4.1.2 RequestID – XML Syntax 4.4.2 Component ResponseID 4.4.2.1 ResponseID – JSON Syntax 4.4.2.2 ResponseID – XML Syntax 4.4.3 Component OptionalInputsBase 4.4.3.1 OptionalInputsBase – JSON Syntax 4.4.3.2 OptionalInputsBase – XML Syntax 4.4.4 Component OptionalInputsSign 4.4.4.1 OptionalInputsSign – JSON Syntax 4.4.4.2 OptionalInputsSign – XML Syntax 4.4.5 Component OptionalInputsVerify 4.4.5.1 OptionalInputsVerify – JSON Syntax 4.4.5.2 OptionalInputsVerify – XML Syntax 4.4.6 Component OptionalOutputsBase 4.4.6.1 OptionalOutputsBase – JSON Syntax 4.4.6.2 OptionalOutputsBase – XML Syntax 4.4.7 Component OptionalOutputsSign 4.4.7.1 OptionalOutputsSign – JSON Syntax 4.4.7.2 OptionalOutputsSign – XML Syntax 4.4.8 Component OptionalOutputsVerify 4.4.8.1 OptionalOutputsVerify – JSON Syntax 4.4.8.2 OptionalOutputsVerify – XML Syntax 4.4.9 Component ClaimedIdentity 4.4.9.1 ClaimedIdentity – JSON Syntax 4.4.9.2 ClaimedIdentity – XML Syntax 4.4.10 Component Schemas 4.4.10.1 Schemas – JSON Syntax 4.4.10.2 Schemas – XML Syntax 4.4.11 Component IntendedAudience 4.4.11.1 IntendedAudience – JSON Syntax 4.4.11.2 IntendedAudience – XML Syntax 4.4.12 Component KeySelector 4.4.12.1 KeySelector – JSON Syntax 4.4.12.2 KeySelector – XML Syntax 4.4.13 Component X509Digest 4.4.13.1 X509Digest – JSON Syntax 4.4.13.2 X509Digest – XML Syntax 4.4.14 Component PropertiesHolder 4.4.14.1 PropertiesHolder – JSON Syntax 4.4.14.2 PropertiesHolder – XML Syntax 4.4.15 Component Properties 4.4.15.1 Properties – JSON Syntax 4.4.15.2 Properties – XML Syntax 4.4.16 Component Property 4.4.16.1 Property – JSON Syntax 4.4.16.2 Property – XML Syntax 4.4.17 Component IncludeObject 4.4.17.1 IncludeObject – JSON Syntax 4.4.17.2 IncludeObject – XML Syntax 4.4.18 Component SignaturePlacement 4.4.18.1 SignaturePlacement – JSON Syntax
-
[기획-디지털 ID 표준] ⑫산업단체와 포럼 - 신속 온라인 인증(Fast Identity Online, FIDO)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.신속 온라인 인증(Fast Identity Online, FIDO)은 2013년 2월 출범한 개방형 산업협회다. 전 세계 비밀번호에 대한 과도한 의존을 줄이는 데 도움이 되는 인증 표준을 개발하고 홍보하는 것을 사명으로 삼고 있다.디지털 ID와 관련된 내용은 로밍 인증자와 다른 클라이언트/플랫폼 간 통신을 위한 어플리케이션 계층 프로토콜을 설명하는 클라이언트-인증자 프로토콜(Client to Authenticator Protocol, CTAP)이다.다양한 물리적 매체를 사용해 이 어플리케이션 프로토콜을 다양한 전송 프로토콜에 결합하고 있다. 클라이언트-인증자 프로토콜(Client to Authenticator Protocol, CTAP) 관련 목차를 살펴보면 다음과 같다.목차(table of contents)1. Introduction1.1 Relationship to Other Specifications2. Conformance3. Protocol Structure4. Protocol Overview5. Authenticator API5.1 authenticatorMakeCredential (0x01)5.2 authenticatorGetAssertion (0x02)5.3 authenticatorGetNextAssertion (0x08)5.3.1 Client Logic5.4 authenticatorGetInfo (0x04)5.5 authenticatorClientPIN (0x06)5.5.1 Client PIN Support Requirements5.5.2 Authenticator Configuration Operations Upon Power Up5.5.3 Getting Retries from Authenticator5.5.4 Getting sharedSecret from Authenticator5.5.5 Setting a New PIN5.5.6 Changing existing PIN5.5.7 Getting pinToken from the Authenticator5.5.8 Using pinToken5.5.8.1 Using pinToken in authenticatorMakeCredential5.5.8.2 Using pinToken in authenticatorGetAssertion5.5.8.3 Without pinToken in authenticatorGetAssertion5.6 authenticatorReset (0x07)6. Message Encoding6.1 Commands6.2 Responses6.3 Status codes7. Interoperating with CTAP1/U2F authenticators7.1 Framing of U2F commands7.1.1 U2F Request Message Framing ### (#u2f-request-message-framing)7.1.2 U2F Response Message Framing ### (#u2f-response-message-framing)7.2 Using the CTAP2 authenticatorMakeCredential Command with CTAP1/U2F authenticators7.3 Using the CTAP2 authenticatorGetAssertion Command with CTAP1/U2F authenticators8. Transport-specific Bindings8.1 USB Human Interface Device (USB HID)8.1.1 Design rationale8.1.2 Protocol structure and data framing8.1.3 Concurrency and channels8.1.4 Message and packet structure8.1.5 Arbitration8.1.5.1 Transaction atomicity, idle and busy states.8.1.5.2 Transaction timeout8.1.5.3 Transaction abort and re-synchronization8.1.5.4 Packet sequencing8.1.6 Channel locking8.1.7 Protocol version and compatibility8.1.8 HID device implementation8.1.8.1 Interface and endpoint descriptors8.1.8.2 HID report descriptor and device discovery8.1.9 CTAPHID commands8.1.9.1 Mandatory commands8.1.9.1.1 CTAPHID_MSG (0x03)8.1.9.1.2 CTAPHID_CBOR (0x10)8.1.9.1.3 CTAPHID_INIT (0x06)8.1.9.1.4 CTAPHID_PING (0x01)8.1.9.1.5 CTAPHID_CANCEL (0x11)8.1.9.1.6 CTAPHID_ERROR (0x3F)8.1.9.1.7 CTAPHID_KEEPALIVE (0x3B)8.1.9.2 Optional commands8.1.9.2.1 CTAPHID_WINK (0x08)8.1.9.2.2 CTAPHID_LOCK (0x04)8.1.9.3 Vendor specific commands8.2 ISO7816, ISO14443 and Near Field Communication (NFC)8.2.1 Conformance8.2.2 Protocol8.2.3 Applet selection8.2.4 Framing8.2.4.1 Commands8.2.4.2 Response8.2.5 Fragmentation8.2.6 Commands8.2.6.1 NFCCTAP_MSG (0x10)8.2.6.2 NFCCTAP_GETRESPONSE (0x11)8.3 Bluetooth Smart / Bluetooth Low Energy Technology8.3.1 Conformance8.3.2 Pairing8.3.3 Link Security8.3.4 Framing8.3.4.1 Request from Client to Authenticator8.3.4.2 Response from Authenticator to Client8.3.4.3 Command, Status, and Error constants8.3.5 GATT Service Description8.3.5.1 FIDO Service8.3.5.2 Device Information Service8.3.5.3 Generic Access Profile Service8.3.6 Protocol Overview8.3.7 Authenticator Advertising Format8.3.8 Requests8.3.9 Responses8.3.10 Framing fragmentation8.3.11 Notifications8.3.12 Implementation Considerations8.3.12.1 Bluetooth pairing: Client considerations8.3.12.2 Bluetooth pairing: Authenticator considerations8.3.13 Handling command completion8.3.14 Data throughput8.3.15 Advertising8.3.16 Authenticator Address Type9. Defined Extensions9.1 HMAC Secret Extension (hmac-secret)10. IANA Considerations10.1 WebAuthn Extension Identifier Registrations11S ecurity ConsiderationsIndexTerms defined by this specificationTerms defined by referenceReferencesNormative ReferencesInformative ReferencesIDL Index
-
[기획-디지털 ID 표준] ⑩산업단체와 포럼 - 클라우드 서명 컨소시엄(CSC)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체가 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼은 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등을 포함한다.클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC)은 클라우드에서 매우 안전하고 규정을 준수하는 디지털 서명의 표준화를 추진하기 위해 노력하는 산업계, 정부, 학계 조직으로 구성된 글로벌 그룹이다.SCS는 REST(representational state transfer)/JSON(JavaScript Object Notation) API(application programming interface)를 사용해 원격 서명을 생성할 수 있는 프로토콜을 개발했다. 프로토콜은 원격 서명 어플리케이션을 위한 아키텍처 및 프로토콜을 말한다.유럽연합(EU_의 전자본인확인·인증·서명(eIDAS) 규정의 엄격한 요구 사항에 따라 CSC는 △용이한 솔루션 상호 운용성 △전자 서명 규정 준수 간소화 △클라우드 기반 디지털 서명의 균일한 채택 등을 공통 기술 사양으로 채택했다.EU의 새로운 식별 및 신뢰 서비스 규정인 eIDAS와 같은 새로운 규정은 전체 글로벌 산업에 영향을 미칠 것으로 예상되는 방식으로 보안 서명에 대한 엄격한 요구 사항을 설정하고 있다.따라서 CSC는 EU 기업 및 정부가 eIDAS 규정을 성공적으로 준수할 수 있도록 하는 것을 목표로 하고 있다. 유럽과 전 세계에 걸쳐 단일 디지털 시장을 창출하는 것이 비전이기 때문이다.
-
[특집-공동기술위원회] ⑤JTC 1/SC 6 시스템 간 통신 및 정보 교환(Telecommunications and information exchange between systems)스위스 제네바에 본부를 두고 있는 국제표준화기구(ISO)에서 활동 중인 기술위원회(Technical Committeee, TC)는 TC1~TC323까지 구성돼 있다.기술위원회의 역할은 기술관리부가 승인한 작업범위 내 작업 프로그램 입안, 실행, 국제규격의 작성 등이다. 또한 산하 분과위원회(SC), 작업그룹(Working Group, WG)을 통해 기타 ISO 기술위원회 또는 국제기관과 연계한다.ISO/IEC 기술작업 지침서 및 기술관리부 결정사항에 따른 ISO 국제규격안 작성·배포, 회원국의 의견 편집 등을 처리한다. 소속 분과위원회 및 작업그룹의 업무조정, 해당 기술위원회의 회의 준비도 담당한다.또한 국제전기기술위원회(International Electro-technical Commission, IEC)는 전기 및 전자 제품의 고품질 인프라와 국제 무역을 뒷받침하는 글로벌 비영리 회원 조직이다.기술 혁신, 저렴한 인프라 개발, 효율적이고 지속 가능한 에너지 접근, 스마트 도시화 및 교통 시스템, 기후 변화 완화를 촉진하고 사람과 환경의 안전을 향상시키는 역할을 수행하고 있다. 170개 이상의 국가를 통합하고 전 세계 2만명의 전문가에게 글로벌하고 중립적이며 독립적인 표준화 플랫폼을 제공하고 있다. 장치, 시스템, 설치, 서비스 및 인력이 필요에 따라 작동함을 구성원이 인증하는 4가지 적합성 평가 시스템을 관리한다.적합성 평가와 함께 정부가 국가 품질 인프라를 구축하고 모든 규모의 기업이 전 세계 대부분의 국가에서 일관되게 안전하고 신뢰할 수 있는 제품을 사고 팔 수 있도록 하는 기술 프레임워크를 제공하는 약 1만개의 IEC 국제표준을 발행하고 있다.이러한 ISO와 IEC가 공동으로 구성한 기술위원회 ISO/IEC JTC 1 정보 기술(Information technology)에 대해 살펴볼 예정이다. JTC 1은 1987년에 결성됐으며 사무국은 미국국립표준협회(American National Standards Institute, ANSI)에서 맡고 있다. 위원회는 리사 라지첼(Mrs Lisa Rajchel)가 책임지고 있다. 현재 의장은 필 웬블롬(Mr Phil Wennblom)으로 임기는 202년까지다.ISO 기술 프로그램 관리자는 앤드류 드라이든(Mr Andrew Dryden), 스티븐 더트널(Mr Stephen Dutnall), ISO 편집 관리자는 앨리슨 레이드 자몬드(Ms Alison Reid-Jamond) 등으로 조사됐다. 범위는 정보기술 분야의 표준화다.현재 ISO/IEC JTC 1의 직접적인 책임 하에 발행된 표준은 517개며 직접적인 책임 하에 개발중인 표준은 23개다. 참여하고 있는 회원은 40개국, 참관 회원은 62개국이다.공동 기술위원회(Joint Technical Committee, JTC) 산하에서 활동하고 있는 분과위원회(Subcommittee, SC) 중 SC 1, SC 2에 이어 SC 6에 대해 살펴보면 다음과 같다.ISO/IEC JTC 1/SC 6 시스템간 통신 및 정보 교환(Telecommunications and information exchange between systems)과 관련된 분과위원회는 1988년 결성됐다. 사무국은 한국 국가기술표준원(Korean Agency for Technology and Standards, KATS)에서 맡고 있다.위원회는 오정엽(Mr Jungyup OH)이 책임지고 있다. 현재 의장은 강현국(Dr Hyun Kook Kahng)으로 임기는 2024년까지다.ISO 기술 프로그램 관리자는 앤드류 드라이든(Mr Andrew Dryden), ISO 편집 관리자는 클라우디아 루에제(Ms Claudia Lueje) 등으로 조사됐다.범위는 사용 조건 뿐 아니라 시스템 기능, 절차, 매개변수를 포함해 개방형 시스템 간의 정보 교환을 다루는 통신 분야 표준화 작업을 진행해 왔다.이 표준화는 물리적, 데이터 링크, 네트워크 및 전송을 포함한 하위 계층의 프로토콜과 서비스뿐만 아니라 디렉토리 및 ASN.1(MFAN, NFC, PLC, 미래 네트워크 및 OID)을 포함하되 이에 국한되지 않는 상위 계층의 프로토콜 및 서비스를 포함하고 있다.현재 ISO/IEC JTC 1/SC 6 사무국의 직접적인 책임 하에 발행된 표준은 397개며 개발 중인 표준은 18개다. 참여하고 있는 회원은 19명, 참관 회원은 36명이다.□ ISO/IEC JTC 1/SC 6 사무국의 직접적인 책임하에 발행된 표준 및(또는) 프로젝트 397개 중 15개 목록▷ISO 1155:1978 Information processing — Use of longitudinal parity to detect errors in information messages▷ISO 1177:1985 Information processing — Character structure for start/stop and synchronous character oriented transmission▷ISO 1745:1975 Information processing — Basic mode control procedures for data communication systems▷ISO 2110:1989 Information technology — Data communication — 25-pole DTE/DCE interface connector and contact number assignments▷ISO 2110:1989/Amd 1:1991 Information technology — Data communication — 25-pole DTE/DCE interface connector and contact number assignments — Amendment 1: Interface connector and contact number assignments for a DTE/DCE interface for data signalling rates above 20 000 bit/s per second▷ISO/IEC 2593:2000 Information technology — Telecommunications and information exchange between systems — 34-pole DTE/DCE interface connector mateability dimensions and contact number assignments▷ISO 2628:1973 Basic mode control procedures — Complements▷ISO 2629:1973 Basic mode control procedures — Conversational information message transfer▷ISO/IEC 4005-1:2023 Telecommunications and information exchange between systems — Unmanned aircraft area network (UAAN) — Part 1: Communication model and requirements▷ISO/IEC 4005-2:2023 Telecommunications and information exchange between systems — Unmanned aircraft area network (UAAN) — Part 2: Physical and data link protocols for shared communication▷ISO/IEC 4005-3:2023 Telecommunications and information exchange between systems — Unmanned aircraft area network (UAAN) — Part 3: Physical and data link protocols for control communication▷ISO/IEC 4005-4:2023 Telecommunications and information exchange between systems — Unmanned aircraft area network (UAAN) — Part 4: Physical and data link protocols for video communication▷ISO 4902:1989 Information technology — Data communication — 37-pole DTE/DCE interface connector and contact number assignments▷ISO 4903:1989 Information technology — Data communication — 15-pole DTE/DCE interface connector and contact number assignments▷ISO/IEC 5021-1:2023 Telecommunications and information exchange between systems — Wireless LAN access control — Part 1: Networking architecture▷ISO/IEC 5021-2:2023 Telecommunications and information exchange between systems — Wireless LAN access control — Part 2: Dispatching platform□ ISO/IEC JTC 1/SC 6 사무국의 직접적인 책임하에 개발중인 표준 및(또는) 프로젝트 18개 중 15개 목록▷ISO/IEC PRF 4396-1 Telecommunications and information exchange between systems — Recursive inter-network architecture — Part 1: Reference model▷ISO/IEC PRF 4396-2 Telecommunications and information exchange between systems — Recursive inter-network architecture — Part 2: Common application connection establishment protocol▷ISO/IEC PRF 4396-3 Telecommunications and information exchange between systems — Recursive inter-network architecture — Part 3: Common distributed application protocol▷ISO/IEC PRF 4396-4 Telecommunications and information exchange between systems — Recursive inter-network architecture — Part 4: Complete enrolment procedures▷ISO/IEC PRF 4396-5 Telecommunications and information exchange between systems — Recursive inter-network architecture — Part 5: Incremental enrolment procedures▷ISO/IEC PRF 4396-6 Telecommunications and information exchange between systems — Recursive inter-network architecture — Part 6: RINA data transfer service▷ISO/IEC PRF 4396-7 Telecommunications and information exchange between systems — Recursive inter-network architecture — Part 7: Flow allocator▷ISO/IEC PRF 4396-8 Telecommunications and information exchange between systems — Recursive inter-network architecture — Part 8: RINA general delimiting procedures▷ISO/IEC PRF 4396-9 Telecommunications and information exchange between systems — Recursive inter-network architecture — Part 9: Error and flow control protocol▷ISO/IEC/IEEE DIS 8802-1Q Telecommunications and exchange between information technology systems — Requirements for local and metropolitan area networks — Part 1Q: Bridges and bridged networks▷ISO/IEC 9594-8:2020/CD Cor 2 Information technology — Open systems interconnection — Part 8: The Directory: Public-key and attribute certificate frameworks — Technical Corrigendum 2▷ISO/IEC 9594-11:2020/CD Cor 1 Information technology — Open systems interconnection directory — Part 11: Protocol specifications for secure operations — Technical Corrigendum 1▷ISO/IEC 9594-11:2020/DAmd 1 Information technology — Open systems interconnection directory — Part 11: Protocol specifications for secure operations — Amendment 1▷ISO/IEC DIS 9594-12 Information technology — Open systems interconnection — Part 12: The Directory: Key management and public-key infrastructure establishment and maintenance▷ISO/IEC FDIS 18092 Telecommunications and information exchange between systems — Near Field Communication Interface and Protocol 1 (NFCIP-1)
-
[기획-디지털 ID 기술] ⑩아이데미아, '디지털 아이디를 위한 사용자 데이터 유효성 검사' 명칭의 미국 특허 등록(US 11509477)미국 바이오 테크 기업 아이데미아(Idemia)에 따르면 2022년 11월22일 '디지털 아이디를 위한 사용자 데이터 유효성 검사(User data validation for digital identifications)' 명칭의 미국 특허(US 11509477)가 등록됐다.본 등록 특허는 2019년 10월8일 등록된 미국 원출원 특허(US 10439815)건을 바탕으로 2019년 10월7일 계속 출원됐다.원출원 등록 특허(US 10439815)는 2014년 12월30일 미국 가출원(US 62/098016) 후 2015년 12월30일 본출원(US 14/984941)됐다.본 등록 특허(US 11509477)에서는 디지털 아이디를 포함하는 사용자 장치가 사용할 수 없거나 현재 네트워크 연결이 부족한 상황에서 디지털 아이디에서 추출된 사용자 데이터 페이지의 유효성을 검사한다.인증된 장치는 근접 기반 데이터 교환 프로토콜(proximity-based data exchange protocol)을 사용해 사용자 장치와 통신을 교환하거나, 사용자 기록에 대한 디지털 아이디를 식별하도록 물리적 식별 카드를 사용하여 사용자의 디지털 아이디를 식별함으로써 디지털 아이디에서 사용자 데이터 페이지를 추출한다.사용자 기록 내의 체크섬과 사용자 데이터 페이지와 연관된 체크섬을 비교한다. 디지털 아이디에 할당된 보안 상태에 따라 가변적으로 지정되는 암호 해독 키를 사용해 사용자 데이터 페이지를 해독함으로써 사용자 데이터 페이지의 유효성이 검사된다.
-
[기획-암호화 이해] ③정보보안 원칙 및 암호화 사용 - 엔티티 인증, 디지털 서명, 부인 방지정보사회의 건전성을 확보하기 위한 암호화(Cryptography)는 정보보안의 핵심 원칙인 기밀성(confidentiality), 무결성(integrity), 가용성(availability) 중 기밀성과 무결성을 확보하는데 매우 중요한 도구다.데이터 기밀성은 데이터가 승인되지 않은 당사자에게 공개되지 않도록 보장하는 것을 말한다. 암호화와 같은 암호화 기술은 데이터 기밀성을 보호하기 위해 사용될 수 있다. 정당한 해독 키(key)를 갖고 있지 않은 사람은 데이터를 읽을 수 없다.데이터 무결성은 데이터가 변조되거나 손상되지 않았음을 확인해준다. 데이터 무결성과 관련된 국제표준 ISO/IEC 9797은 메시지 인증 코드 계산을 위한 알고리즘을 지정한다.암호화는 주요 정보 보안 목표 외에도 △엔티티 인증(entity authentication) △디지털 서명(digital signatures) △부인 방지(non-repudiation) △경량 암호화(Lightweight cryptography) △디지털 권한 관리(Digital rights management, DRM) △전자상거래(e-commerce) 및 온라인 쇼핑(online shopping) △암호화폐(cryptocurrency) 및 블록체인(blockchain) 등에도 사용되고 있다.첫 번째, 엔티티 인증(entity authentication)은 비밀에 대한 지식을 확인해 발신자의 신원을 증명하는 것을 말한다. ISO/IEC 9798는 엔티티 인증 및 프로토콜, 기술 등을 지정하는 일련의 국제표준이다.이를 달성할 수 있는 다양한 암호화 기반 메커니즘과 프로토콜이 있다. 대칭 시스템(symmetric systems), 디지털 서명(digital signatures), 영지식 기술(zero-knowledge techniques), 체크섬(checksums) 등이 대표적이다.두 번째, 디지털 서명(digital signatures)은 데이터가 서명자로부터 생성됐으며 변경되지 않았음을 확인함으로서 데이터의 신뢰성을 확인하는 데 사용된다. 디지털 서명은 이메일 메시지, 전자 문서, 온라인 결제 등에 활용된다.디지털 서명 체계를 지정하는 국제표준에는 ISO/IEC 9796, ISO/IEC 14888, ISO/IEC18370, ISO/IEC 20008 등이 있다.세 번째, 부인 방지(non-repudiation)는 디지털 서명과 같은 암호화 기술을 사용해 메시지를 보낸 사람과 받은 사람이 각각 메시지슬 수발신했다는 사실을 부인할 수 없도록해 보장하기 위해 사용된다.부인 방지에는 송신 부인 방지, 송달 부인 방지, 수신 부인 방지 등이 있다. 표준 ISO/IEC 13888은 부인 방지 서비스 제공을 위한 기술, 즉대칭 및 비대칭 기술을 설명한다.
-
[기획-디지털 ID 표준] ②디지털 ID 표준 개발 기관 및 조직컴퓨터와 인터넷의 보급으로 정보사회가 진전되면서 전 세계가 하나의 글로벌 빌리지, 즉 지구촌으로 동화되고 있다. 디지털 혁명은 디지털 서비스와 전자성거래의 발전을 가속화시켰다.2020년 1월부터 확산된 코로나19 팬데믹(대유행) 영향으로 대면 접촉이 제한되면서 비대면 서비스의 중요성은 높아졌다. 사이버 세상에서 상호작용이 증가하며 덩달아 전자거래 사기도 늘어났다.개인의 신원을 조작하거나 위변조할 수 있는 기술이 개발됐기 때문이다. 이로써 법인이나 개인 또는 전자 서비스 내 실체를 식별하는 디지털 신원(Digital identity)의 중요성이 부각됐다.디지털 신원 즉 디지털 ID 영역에는 다양한 표준이 있다. 디지털 ID 표준은 △정책 설명 △디지털 ID 발급 및 관리 서비스 △사용할 형식 및 프로토콜 △관련 서비스 감사 방법 △서비스 장치에 대한 요구사항 △추천하는 프로세스 및 알고리즘 등을 포함한다.디지털 ID 표준 개발은 유럽표준화기구, 국제표준화기구, 상업 포럼 및 컨소시업 등 다양한 기관과 조직이 수행하고 있다. 세부적으로 살펴보면 다음과 같다. ▶유럽 표준화 기구(European standardisation organisations) - 유럽전기통신표준협회(European Telecommunications Standards Institute, ETSI) - 유럽표준화위원회(European Committee for Standardization, CEN) - 유럽전기표준화위원회(European Committee for Electrotechnical Standardization, CENELEC)▶국제표준화기구(international standardisation organisations) - 세계표준화기구(International Organization for Standardization, ISO) - 국제전기통신연합(International Telecommunication Union, ITU) - 미국 전기전자공학자협회(Institute of Electrical and Electronics Engineers, IEEE) - 국제전기기술위원회(International Electrotechnical Commission, IEC) - 정보기술보안평가 공통기준(Common Criteria for Information Technology Security Evaluation, Common Criteria) - 유엔 국제민간항공기구(International Civil Aviation Organization, ICAO)▶상업 포럼 및 컨소시엄(commercial forums and consortia) - 국제인터넷표준화기구(Internet Engineering Task Force, IETF) - 인증기관 브라우저 포럼(Certification Authority Browser Forum, CABF) - 클라우드 시그니처 컨소시엄(Cloud Signature Consortium, CSC) - 오아시스(Organization for the Advancement of Structured Information Standards, OASIS) - OpenID 재단(OpenID Foundation, OpenID) - FIDO 얼라이언스(FIDO Alliance, FIDO)▶국가 조직(national organisations) - 프랑스 정보시스템 보안기구(Agence nationale de la sécurité des systèmes d’information, ANSSI) - 독일 사이버보안 당국(Bundesamt für Sicherheit in der Informationstechnik, BSI) - 영국표준협회(British Standards Institution, BSI) - 미국 국립표준기술원(National Institute of Standards and Technology, NIST) 일반적으로 처음 제정하는 표준은 공통된 작업 방식에 동의하는 것을 중요하게 여겨 프로토콜 및 형식과 같은 상호 운용성에 초점을 맞춘다. 디지털 ID도 예외는 아니었다.이후 장치 인증뿐만 아니라 서비스 제공업체의 정책 요구사항에 대한 보안 관련 표준이 제정됐다. 이를 통해 모범 사례를 설명하고 유사한 수준의 보안을 설정했다.
-
[미국] 태양광산업협회(SEIA), ANSI로부터 11개 새로운 태양광 및 에너지 저장 표준 개발 승인 획득미국 태양광산업협회(Solar Energy Industries Association, SEIA)에 따르면 미국표준협회(American National Standards Institute, ANSI)로부터 11개의 신규 태양광 및 에너지 저장 표준을 개발하기 위한 승인을 받았다.공인 표준개발기관으로 승인된지 두 달도 채 되지 않아 11개의 신규 표준 개발에 참여하게 된 것이다. SEIA가 ANSI로부터 승인 받아 새롭게 개발하려는 표준 11개는 다음과 같다.▷태양열 및 에너지 저장 공급망 추적 표준▷태양열 및 에너지 저장 설치 요구 사항 표준 : 주거용 시스템▷태양열 및 에너지 저장 설치 요구 사항 표준 : 주거용 시스템 설치자 교육▷태양열 및 에너지 저장 설치 요구 사항 표준 : 상업용 및 산업 시스템▷태양열 및 에너지 저장 설치 요구 사항 표준 : 상업용 및 산업용 시스템 설치자 교육▷태양열 및 에너지 저장 운용 및 유지 관리 표준 : 기술자 교육▷태양열 및 에너지 저장 소비자 보호 표준▷태양열 및 에너지 저장 환경, 건강, 안전 표준 : 설치자 및 기술자 교육▷태양열 및 에너지 저장 장치 폐기 표준▷재활용 업체를 위한 태양열 장비 최소 요건▷태양열 설비 성능 종료/수명 종료 관리 기준SEIA의 첫 번째 표준기술위원회는 공급망 추적 표준 개발을 우선해 2024년 초 발행할 예정이다. SEIA의 추적성 프로토콜 기반으로 미국 내 설치된 태양열 및 저장 제품의 윤리적이고 지속 가능한 방식으로 공급되도록 보장하기 위함이다.SEIA는 태양열 및 저장 산업이 빠르게 성장함에 따라 산업 성장을 관리하는 것이 최우선 과제로 하고 있다. 또한 책임 있는 산업의 안전과 지속 가능성, 윤리에 대한 지침 기준을 설정할 방침이다.청정 에너지 부문 고객, 입법자, 기타 중요한 파트너에게 신뢰를 심어주기 위해 규정을 준수하고 성숙의 시대로 견인을 목표로 삼고 있다.SEIA는 청정 에너지경제로 전환을 주도하고 있다. 2030년까지 국내 전력 생산량의 30%를 태양광 발전으로 달성하기 위한 프레임워크를 준비하는 이유다.1974년 설립해 태양열, 태양열+저장산업을 위한 전국 무역협회, 연구 및 교육, 지지를 통한 '태양열+10년'과 관련된 포괄적 비전을 구축했다.
-
ETRI, 근거리무선통신 기반 인터넷 통신기술 국제표준 제정한국전자통신연구원(ETRI)이 10cm 이내에서 주로 활용하던 근거리무선통신(NFC) 기술에서 인터넷 통신이 가능토록 국제표준화에 성공했다. ETRI는 국제인터넷표준화기구(IETF)에서 사물인터넷 저전력 통신기술인 ‘근거리무선통신(NFC) 기반 인터넷 통신기술’ 표준(RFC 9428)이 국제표준으로 최종 제정됐다고 10일 밝혔다. 근거리무선통신은 그동안 근거리의 기기나 장치 간의 통신에서 주로 사용됐다. 하지만 ETRI가 개발한 표준 ‘RFC 9428’을 적용하면 근거리무선통신 환경에서도 인터넷 사용이 가능해진다. 근거리무선통신 기반 인터넷 통신을 이용하면 NFC 기기 간의 결제 환경에서도 인터넷 기반 통신이 가능해진다. 이를 통해 오프라인 가맹점들은 별도의 전용 결제 단말기 추가설치 없이 기존의 NFC 결제서비스를 이용할 수 있다. 일상에서 흔히 사용되는 와이파이(Wi-Fi) 및 블루투스 기술은 비교적 넓은 구간의 무선 전파환경에서 통신한다. 하지만 해당 기술은 평균 10cm 이내의 좁은 전파 구간에서 통신하기에 와이파이나 블루투스보다 해킹의 위험성에 노출될 우려가 적다. 따라서 무선통신 구간에서 안전하게 데이터를 보낼 수 있다. 또한 해당 기술은 ETRI 표준연구본부가 세계 최초로 보유하고 있는 독자 기술이다. 이번 국제표준 선점과 동시에 국제표준특허를 확보하게 됨에 따라 향후 국내·외 사물인터넷 서비스 관련 신규 결제 및 인증시장에서 고부가가치 성과 창출의 교두보가 될 것으로 평가받고 있다. 더불어 ETRI는 비접촉식 근거리무선통신을 활용하는 스마트 홈, 스마트 빌딩, 스마트 공장과 같은 다양한 사물인터넷 온·오프라인 서비스 환경에서 요구하는 다양한 형태의 결재 및 통신 환경으로 활용하는데 매우 유용할 것이라고 언급했다. 연구진은 이번 RFC 9428 표준을 개발하는 과정에서 유럽전기통신표준협회(ETSI)가 주최한 상호운용성 시험 행사도 높은 점수로 항목을 통과했다. 강신각 ETRI 표준연구본부장은 “이번 국제표준 제정은 독자 표준기술 개발과 표준특허 확보를 확보했다는데 큰 의미가 있다”며 “사물인터넷 분야의 혁신을 주도하고 미래시장 선점으로 이어질 수 있는 값진 성과”라고 말했다. 한편 ETRI는 IETF에서 지금까지 차세대인터넷프로토콜(IPv6), 모바일 기술, 사물인터넷 기술 등 총 15건 이상의 국제표준을 제정하는 등 지속적인 표준화 활동 및 연구를 수행해 오고 있다.