ASN.1

ASN.1

추상 구문 표기법 1
상태	유효, X.208 및 X.209(1988) 대체
년도시작	1984
최신 버전	(02/21) 2021년 2월
조직	ITU-T
기준 표준	ASN.1
관련규격	X.208, X.209, X.509, X.680, X.681, X.682, X.683
도메인	암호학, 통신
웹사이트	https://www.itu.int/rec/T-REC-X.680/

추상 구문 표기법 1(ASN.1)은 교차 플랫폼 방식으로 직렬화 및 탈직렬화가 가능한 데이터 구조를 정의하기 위한 표준 인터페이스 기술 언어다. 그것은 통신과 컴퓨터 네트워킹, 특히 암호학에서 널리 사용된다.^[1]

프로토콜 개발자들은 ASN.1 모듈에서 데이터 구조를 정의하는데, 일반적으로 ASN.1 언어로 작성된 더 넓은 표준 문서의 한 섹션이다. 이점은 데이터 인코딩에 대한 ASN.1 설명이 특정 컴퓨터 또는 프로그래밍 언어와 무관하다는 것이다. ASN.1은 사람이 읽을 수 있고 기계가 읽을 수 있기 때문에, ASN.1 컴파일러는 데이터 구조를 디코딩하거나 인코딩하는 코드, 코덱의 라이브러리로 모듈을 컴파일할 수 있다. 일부 ASN.1 컴파일러는 포장된 BER 또는 XML과 같은 여러 인코딩을 인코딩하거나 디코딩하는 코드를 생성할 수 있다.

ASN.1은 ITU-T 연구 그룹 17과 ISO/IEC에 있는 국제전기통신연합 전기통신 표준화 부문(ITU-T)의 공동 표준으로, 원래 1984년에 CCITT X.409:1984의 일부로 정의되었다.^[2] 1988년, ASN.1은 넓은 적용 가능성 때문에 자체 표준인 X.208로 이전하였다. 1995년 개정판은 X.680 시리즈에서 다룬다.^[3] X.680 시리즈 추천 시리즈의 최근 개정판은 2021년에 발행된 6.0 Edition이다.

언어 지원

ASN.1은 데이터 유형 선언 표기법이다. 그러한 유형의 변수를 어떻게 조작하는지는 정의하지 않는다. 변수 조작은 실행 가능한 모델링을 위한 SDL(Specification and Description Language) 또는 적합성 테스트를 위한 TTCN-3(Testing and Test Control Notice)와 같은 다른 언어로 정의된다. 이 두 언어 모두 ASN.1 선언을 기본적으로 지원한다. ASN.1 모듈을 가져와 모듈에 선언된 ASN.1 유형의 변수를 선언할 수 있다.

적용들

ASN.1은 많은 수의 프로토콜을 정의하는데 사용된다. 그것의 가장 광범위한 용도는 통신, 암호, 생체 인식이다.

인코딩

ASN.1은 데이터 구조를 일련의 바이트로 나타내는 방법을 지정하는 인코딩 규칙 집합과 밀접하게 연관되어 있다. 표준 ASN.1 인코딩 규칙에는 다음이 포함된다.

인코딩 제어 표기법

ASN.1 권장사항은 미리 정의된 여러 인코딩 규칙을 제공한다. 기존 인코딩 규칙 중 어느 것도 적합하지 않은 경우, ECN(인코딩 제어 표기법)은 사용자가 자신의 사용자 정의된 인코딩 규칙을 정의할 수 있는 방법을 제공한다.

PEM(개인 정보 향상 메일) 인코딩 관련 정보

PEM(Privacy-Enhanced Mail) 인코딩은 ASN.1과 완전히 무관하며, 그러나 그 코덱은 종종 ASN.1 데이터(종종 이진)로 인코딩된다. 이것은 복사 및 붙여넣기뿐만 아니라 SMTP 릴레이와 같이 텍스트 인코딩에 민감한 미디어를 통한 전송을 지원할 수 있다.

예

가상 Foo 프로토콜의 메시지(데이터 구조)를 정의하는 ASN.1 모듈의 예:

FooProtocol Definitions ::=BEING FooQuest ::=SEXUR { trackingNumber 정수, 문제 IA5String } FooAns ::=SEQUE { questionNumber 정수, 응답 BOOLND}

이것은 Foo Protocol의 창작자들이 발표한 명세서일 수 있다. 대화 흐름, 거래 간 변화 및 상태는 ASN.1에서 정의되지 않고 프로토콜의 다른 표기 및 텍스트 설명에 맡겨진다.

Foo 프로토콜을 준수하고 수신자에게 전송되는 메시지를 가정하면, 이 특정 메시지(프로토콜 데이터 단위(PDU))는 다음과 같다.

myQuestion Fooquest ::={ trackingNumber 5, "거기 누구 있어?" }

ASN.1은 값과 크기, 그리고 확장성에 대한 제약을 지원한다. 위의 사양은 다음과 같이 변경할 수 있다.

FooProtocol DEFINITIONS ::= BEGIN      FooQuestion ::= SEQUENCE {         trackingNumber INTEGER(0..199),         question       IA5String     }      FooAnswer ::= SEQUENCE {         questionNumber INTEGER(10..20),         answer         BOOLEAN     }      FooHistory ::= SEQUENCE {         questions SEQUENCE(SIZE(0..10)) OF FooQuestion,         ans시퀀스(크기(1..))를 선택하십시오.10) FooAnswer의 FooAnswer, anArray Sequence (100) 정수(0..1000), ...

이러한 변화는 추적 번호의 값이 0에서 199 사이, 질문 번호의 값이 10에서 20 사이인 것을 제한한다. 문제 배열의 크기는 0~10개 요소 사이일 수 있으며, 답 배열이 1~10개 요소 사이일 수 있다. anArray 필드는 0 ~ 1000 범위에 있어야 하는 고정 길이 100 요소 배열이다. ''확장성 마커'는 FooHistory 메시지 규격에 향후 버전의 추가 필드가 있을 수 있다는 것을 의미한다. 한 버전을 준수하는 시스템은 이전 버전에서 지정한 필드만 처리할 수 있지만 이후 버전에서 트랜잭션을 수신하고 전송할 수 있어야 한다. 좋은 ASN.1 컴파일러는 (C, C++, Java 등) 소스 코드를 생성하여 트랜잭션이 이러한 제약조건에 속하는지 자동으로 확인한다. 제약을 위반하는 거래는 애플리케이션에서 수용하거나 애플리케이션에 제시해서는 안 된다. 이 계층의 제약조건 관리는 애플리케이션들이 제약조건 위반으로부터 보호되어 위험과 비용을 줄일 것이기 때문에 프로토콜 명세서를 상당히 단순화한다.

네트워크를 통해 myQuery 메시지를 보내기 위해 메시지는 인코딩 규칙 중 하나를 사용하여 일련의 바이트로 직렬화(인코딩)된다. Foo 프로토콜 명세서는 Foo 프로토콜 사용자가 사용해야 할 인코딩 규칙과 예상할 인코딩 규칙 세트를 명시적으로 지정해야 한다.

DER로 인코딩된 예제

아래는 FooQuestion이 DER 형식으로 인코딩된 데이터 구조(모든 숫자는 16진수)이다.

30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

DER는 형식 길이-값 인코딩이므로 위의 시퀀스는 다음과 같이 표준 SEQUENT, IA5String 유형을 참조하여 해석할 수 있다.

SEXUR 13을 나타내는 30 — 02 — 값의 8진수 길이 01 — 05 — 값 (5) 16 — IA5 String을 나타내는 유형 태그(IA5는 변형을 포함한 전체 7비트 ISO 646 세트를 의미하지만 일반적으로 US-ASCII) 0e — 길이 ta 값 10진 길이t는 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f - 값("거기 누구라도?")을 따른다. 

XER로 인코딩된 예제

또는 XML 인코딩 규칙(XER)으로 동일한 ASN.1 데이터 구조를 인코딩하여 "전선을 통해" 인간의 가독성을 높일 수 있다. 다음 108 옥텟으로 표시된다(공간 카운트는 들여쓰기에 사용되는 공간을 포함한다).

<후유 질문> <추적번호>5</추적번호> <질문>거기 누구 있어?</질문> </질문> 

PER로 인코딩된 예(비정렬)

또는 포장 인코딩 규칙을 사용할 경우 다음과 같은 122비트(16옥텟은 128비트에 해당하지만 여기서는 122비트만 정보를 전달하고 마지막 6비트는 패딩에 불과하다)가 생성된다.

01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 a3 2f af 2c a0

이 형식에서는 필수 요소의 태그가 인코딩되지 않으므로 인코딩에 사용되는 예상 스키마를 알지 못하면 구문 분석할 수 없다. 또한 인코더는 IA5String 바이트 값을 인코딩하면 7비트만 필요하다는 것을 알기 때문에 IA5String 값의 바이트는 8비트 단위 대신 7비트 단위를 사용하여 포장된다. 그러나 첫 번째 정수 태그 01에 대해서도 길이 바이트는 여전히 인코딩되어 있다(그러나 PER 패커는 허용 값 범위가 8비트에 맞는지 알고 있고, 허용 값이 더 작은 범위에만 들어갈 수 있다는 것을 알고 있다면 8비트 이하로 단일 값 바이트 05를 압축할 수도 있다).

인코딩된 PER의 마지막 6비트는 마지막 바이트 c0의 6개 최하위 비트에 null 비트로 패딩된다. 이러한 추가 비트는 더 긴 정렬되지 않은 PER 시퀀스의 일부로 삽입된 경우 다른 비트를 인코딩하는 데 전송되거나 사용될 수 없다.

즉, 정렬되지 않은 PER 데이터는 기본적으로 정렬된 PER과 같이 순서가 정해진 바이트 스트림이 아니라 순서가 정해진 비트 스트림이며, 직접 바이트 어드레싱이 아닌 추가적인 상황별 비트-시프팅과 마스킹이 필요하기 때문에 일반 프로세서에서 소프트웨어로 디코딩하는 것이 좀 더 복잡할 것이다(그러나 동일한 언급은 tr.최소 주소 지정 가능 단위가 1 옥텟보다 큰 최신 프로세서 및 메모리/스토리지 단위를 가진 ue). 그러나 현대의 프로세서와 신호 프로세서는 주소 지정 가능한 스토리지 유닛의 경계를 넘어서는 컴퓨팅 유닛의 자동 처리를 통해 비트 스트림의 빠른 내부 디코딩을 위한 하드웨어 지원을 포함한다(압축/압축용 데이터 코덱 또는 일부 암호화/암호 해독 알고리즘을 사용하여 효율적인 처리를 위해 필요).ms).

옥텟 경계에서 정렬해야 하는 경우 정렬된 PER 인코더는 다음을 생성한다.

01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

(이 경우, 각 옥텟은 사용되지 않은 가장 중요한 비트에 null 비트로 개별적으로 패딩된다.)

도구들

ASN.1을 지원하는 대부분의 도구는 다음을 수행한다.

• ASN.1 파일 구문 분석,
• 등가 선언을 프로그래밍 언어로 생성(예: C 또는 C++)
• 이전 선언에 기반한 인코딩 및 디코딩 함수를 생성한다.

ASN.1을 지원하는 툴 목록은 ITU-T Tool 웹 페이지에서 확인할 수 있다.

온라인 도구

• ASN1 웹 도구(매우 제한적)
• ASN1 플레이그라운드(샌드박스)

유사한 계획과 비교

ASN.1은 프로토콜 버퍼와 Apache Saleft와 용도가 유사하며, 이는 교차 플랫폼 데이터 직렬화를 위한 인터페이스 설명 언어이기도 하다. 그러한 언어와 마찬가지로, 그것은 스키마(ASN.1에서는 "모듈"이라고 불림), 그리고 전형적으로 길이-값 인코딩의 집합이 있다. 이들와는 달리 ASN.1은 쉽게 사용할 수 있는 단일 오픈 소스 구현을 제공하지 않으며, 제3자 벤더가 구현해야 할 사양으로 공표되고 있다. 그러나 1984년에 정의한 ASN.1은 수년이 지나도록 그들을 앞질렀다. 또한 더 다양한 기본 데이터 유형을 포함하며, 그 중 일부는 구식이고 확장성을 위한 더 많은 옵션을 가지고 있다. 단일 ASN.1 메시지에는 복수의 표준에 정의된 복수의 모듈, 심지어 몇 년 간격으로 정의된 표준의 데이터가 포함될 수 있다.

ASN.1은 또한 값과 크기에 대한 제약에 대한 내장된 지원을 포함한다. 예를 들어, 모듈은 0 ~ 100 범위에 있어야 하는 정수 필드를 지정할 수 있다. 일련의 값(배열)의 길이도 고정 길이 또는 허용되는 길이의 범위로 지정할 수 있다. 제약조건은 기본 제약조건 집합의 논리적 조합으로도 지정할 수 있다.

제약조건으로 사용되는 값은 PDU 규격에 사용된 리터럴이거나 스키마 파일의 다른 곳에 지정된 ASN.1 값일 수 있다. 일부 ASN.1 도구는 생성된 소스 코드의 프로그래머가 이러한 ASN.1 값을 사용할 수 있게 한다. 정의되고 있는 프로토콜의 상수로써, 개발자들은 프로토콜의 논리 구현에서 이것들을 사용할 수 있다. 따라서 모든 PDU와 프로토콜 상수는 스키마에서 정의될 수 있으며, 지원되는 언어에서 프로토콜의 모든 구현은 그러한 값에 의존한다. 이것은 개발자들이 그들의 구현의 소스 코드에 프로토콜 상수를 손으로 코드화할 필요가 없게 한다. 이것은 프로토콜 개발에 크게 도움이 된다; 프로토콜의 상수는 ASN.1 스키마에서 변경될 수 있고 모든 구현은 재컴파일하여 신속하고 낮은 위험 개발 주기를 촉진함으로써 업데이트된다.

ASN.1 도구가 생성된 소스 코드에서 제약조건 점검을 적절하게 구현한다면, 이는 프로그램 운영 중에 프로토콜 데이터를 자동으로 검증하는 역할을 한다. 일반적으로 ASN.1 도구는 생성된 직렬화/직렬화 루틴에 대한 제약조건을 포함하며, 범위를 벗어난 데이터가 발생할 경우 오류 또는 예외를 발생시킨다. ASN.1 컴파일러에서 ASN.1 제약의 모든 측면을 구현하는 것은 복잡하다. 모든 도구가 가능한 제약 조건 표현식의 전체 범위를 지원하는 것은 아니다. XML 스키마와 JSON 스키마는 모두 유사한 제약조건 개념을 지원한다. 제약을 위한 도구 지원은 다양하다. 마이크로소프트사의 xsd.컴파일러는 그들을 무시한다.

ASN.1은 HTTP, SMTP와 같은 많은 인터넷 프로토콜을 정의하는 데 사용되는 증강 백커스-나우르 양식(ABNF)과 시각적으로 유사하다. 그러나 실제로는 상당히 다르다. ASN.1은 다양한 방법으로 인코딩될 수 있는 데이터 구조를 정의한다(예: JSON, XML, 이진). 반면 ABNF는 데이터 구조("syntax")를 정의하는 동시에 인코딩("syntax")을 정의한다. ABNF는 텍스트, 사람이 판독할 수 있는 프로토콜을 정의하는 데 더 자주 사용되는 경향이 있으며, 일반적으로 형식 길이-값 인코딩을 정의하는 데는 사용되지 않는다.

많은 프로그래밍 언어가 언어별 직렬화 형식을 정의한다. 예를 들어 파이썬의 '피클' 모듈과 루비의 '마르샬' 모듈이 그것이다. 이러한 형식은 일반적으로 언어마다 다르다. 또한 스키마가 필요하지 않으므로 임시 스토리지 시나리오에서 사용하기 쉽지만 통신 프로토콜에는 적합하지 않다.

JSON과 XML도 마찬가지로 스키마가 필요하지 않아 사용이 편리하다. 그러나, 그것들은 둘 다 교차 플랫폼 표준이며, 특히 JSON 스키마나 XML 스키마와 결합했을 때 통신 프로토콜에 널리 인기가 있다.

일부 ASN.1 도구는 ASN.1과 XML 스키마(XSD) 사이를 번역할 수 있다. 그 번역은 ITU에 의해 표준화되었다. 이것은 프로토콜이 ASN.1에서 정의되고 또한 XSD에서도 자동으로 정의되는 것을 가능하게 한다. 따라서 프로젝트에서 ASN.1 도구에 의해 컴파일되고 있는 XSD 스키마가 JSON 와이어포맷으로 객체를 직렬화하는 소스 코드를 생성하는 것이 가능하다(잘못 고안된 것일 수도 있음). 보다 실용적인 용도는 다른 하위 프로젝트가 ASN.1 스키마 대신 XSD 스키마를 소비할 수 있도록 허용하는 것으로, 아마도 XER를 프로토콜 와이어포맷로 사용하는 하위 프로젝트 언어에 사용할 수 있는 도구를 사용할 수 있도록 하는 것이다.

자세한 내용은 데이터 직렬화 형식 비교를 참조하십시오.

참고 항목

• X.690
• 정보 객체 클래스(ASN.1)
• 프리젠테이션 레이어

참조

외부 링크

• ASN.1, BER 및 DER의 서브셋에 대한 일반 가이드 초보자를 위한 좋은 소개
• ITU-T 웹사이트 - ASN.1 소개
• ASN.1 비디오 소개
• ASN.1 기본 ASN.1 개념에 대한 자습서
• ASN.1에 대한 자습서
• 오픈 소스 ASN.1->C++ 컴파일러; 일부 ASN.1 사양, 온라인 ASN.1->C++ 컴파일러 포함
• ASN.1 디코더 ASN.1 인코딩된 메시지를 XML 출력으로 디코딩할 수 있다.
• ASN.1 구문 검사기 및 인코더/데코더 ASN.1 스키마의 구문을 확인하고 메시지를 인코딩/데코더.
• 3GPP 메시지의 ASN.1 인코더/데코더 ASN.1 3GPP 메시지를 인코딩/데코더하고 이러한 메시지의 손쉬운 편집을 가능하게 한다.
• ASN.1에 대한 무료 도서
• IvmaiAsn 프로젝트의 ASN.1 도구 목록
• OER(Octet Encoding Rule) 개요
• JSON 인코딩 규칙(JER) 개요
• ASN.1 메시지를 구문 분석 및 검증하기 위한 Typescript 노드 유틸리티