제1장 일반사항
1.1 목적
이 규격은 행정기관에서 전자문서 위ㆍ변조 여부 등 진본성 검증 서비스를 제공하기 위하여 정부 전자문서진본확인센터(GTSA, Government Time Stamp Authority)을 이용하려는 경우 준용할 수 있도록 진본확인 서비스 연계 기술규격을 명시하고 있다.
1.2 적용범위
본 기술규격은, 행정기관에서 진본확인 서비스를 제공하기 위해 정부 진본확인센터(GTSA)에서 시점확인 토큰을 발급받아, 이를 전자문서(PDF)에 반영하고 검증하는 방식에 대하여 규정한다. 각급 기관에서 정부 진본확인센터(GTSA)를 통해 진본확인 서비스를 제공하고 검증하기 위한 API 개발ㆍ도입 시 본 기술규격을 준용하여야 한다.
1.3 규격(표준) 관리 주체
○ 본 기술 규격(표준)은 행정안전부 장관이 유지ㆍ관리한다.
1.4 규격(표준) 관리 방안
○ 본 기술규격을 이용하는 기관은 관련 법령의 개정, 기술의 발전 등으로 인해 본 기술 규격(표준)의 개정이 필요할 경우에는 행정안전부 장관에 개정을 요청한다.
○ 행정안전부 장관은 개정(안)을 마련하고 관련 기관의 의견 수렴을 거쳐 본 기술규격을 개정한다.
1.5 용어정의
이 표준의 목적을 위하여 다음의 용어와 정의를 적용한다.
○ 시점확인(TS, Time Stamp)： 어느 시점에 데이터가 존재했다는 사실과 그 시간 이후 내용이 변경되지 않았음을 증명하기 위하여 특정 위치에 표시하는 시각. 공통적으로 참고하는 시각에 대해 시간의 기점을 표시하는 시간 변위 매개 변수이다.
○ 시점확인 기관(TSA, Time Stamp Authority)： 시점 확인 토큰을 생성하고 발급하는 기관. 시점 확인을 요청한 전자 문서에 대하여 당해 전자 문서가 인증기관에 제시된 특정 시점을 확인하여 알려주는 기관이다.
○ 시점확인 토큰(TST, Time-Stamp Token)： 시간 정보가 포함된 시점 확인 토큰으로 데이터 항목의 표현과 시간 값 사이에 검증가능한 암호학적 바인딩을 포함하는 데이터 구조임. 행정전자서명 인증관리센터의 시점확인 서버(GPKI-TSA) 또는 전자문서 진본확인센터의 시점확인 서버(GTSA-TSA) 에서 발급됨.
○ 시점확인 프로토콜(TSP, Time-Stamp Protocol)： 공개키 기반구조에서 시점 확인 기관(TSA: time stamping authority)의 역할 및 서비스 요구사항을 정의한 프로토콜. RFC 3161에 정의되어 있으며, 시점확인 메시지의 요구 및 응답의 형식과 전송 프로토콜을 기술하고 있다.
○ 시점확인 서비스(TSS, Time-Stamp Service)： 특정 시점에 해당 데이터가 존재하였음을 제3의 신뢰기관(TTP: Trusted Third Party)이 제공해주는 서비스. 데이터가 특정 시점에 존재하였음을 객관적으로 증명하기 위해서, 해당 데이터와 시점확인 기관(TSA: time stamp authority)이 제공하는 시간 값을 결합시킨 것으로, 데이터 전송 시 해당 데이터가 노출되지 않게 원시 데이터의 해시값을 사용함으로써 데이터의 무결성과 기밀성을 확보하게 된다.
○ 해시함수(Hash Function)： 임의의 길이의 문자열을 고정된 길이의 이진 문자열로 매핑하여 주는 함수. 데이터를 자르고, 치환하거나 위치를 바꾸는 방법들로 결과를 만들어내며, 이 결과를 해시 값(hash value)이라 한다. 해시 함수는 데이터의 무결성, 인증, 부인방지 들에서 응용되는 중요한 함수 가운데 하나이다.
○ 전자서명(Digital Signature)： 서명자를 확인하고 서명자가 문서에 서명하였음을 나타내기 위하여 당해 전자문서에 첨부되거나 논리적으로 결합된 전자적 형태의 정보.
○ 인증서(Certificate)： 인증 기관의 고유 키 또는 비밀 키를 사용하여 변조를 불가능하게 한 개체의 데이터.
○ 인증서 폐기목록(CRL, Certificate Revocation List)： 폐기된 인증서를 이용자 들이 확인할 수 있도록 그 목록을 배포, 공표하기 위한 메커니즘. 주로 인증기관에서 관리하며 메시지를 전달할 때 인증서와 함께 전달된다. 인증서 폐기 목록에는 취소된 인증서들의 일련번호가 들어 있으며 이를 받은 당사자는 목록을 참조하여 취소된 인증서를 사용하지 않도록 해야 한다.
○ 인증 경로(Authentication Path)： 클라이언트(client)가 신뢰하고 있는 공개 키 (PKI)가 속한 인증서에서 시작하여 클라이언트가 유효성을 검증해야 할 공개 키 를 포함한 인증서까지 모든 인증서들을 순서적으로 모아둔 인증서 목록.
○ 객체 식별자(OID, Object IDentifier)： 국제표준화기구(ISO)와 국제전기통신연합(ITU) 등이 정보 보안 암호 코드, 속성, 알고리듬 같은 모든 사물과 객체를 세계적으로 고유 번호 하나로 구별하려고 마련한 국제표준 식별 체계.
○ 다목적 인터넷 전자우편(MIME, Multipurpose Internet Mail Extensions)：
아스키(ASCII) 형식이 아닌 텍스트나 화상, 음성, 영상 등 멀티미디어 데이터를 그대로 전자 우편으로 송신하기 위한 간이 전자 우편 전송 프로토콜(SMTP)의 확장 규격.
○ 암호메세지 구문(CMS, Cryptographic Message Syntax)： 전자 서명, 압축, 인증, 암호문 등에 대한 구문. PKCS #7 암호 메시지 구문 표준에서 나온 것으로, 추상 구문 기법1(ASN. 1) 중 기본 부호화 규칙(BER)을 사용한다. 데이터 보호를 위한 요약 구문으로, 하나의 요약 구문이 다른 구문을 내포하는 복합 구문이 가능하다. 또한 디지털 인증서 기반의 키 관리를 위한 다양한 구조로 되어 있다.
○ 인터넷 엔지니어링 태스크 포스 (IETF, Internet Engineering Task Force)： 인터넷 아키텍처 위원회(IAB) 산하의 조직으로 인터넷의 운영, 관리 및 기술적인 쟁점 등을 해결하는 것을 목적으로 망 설계자, 관리자, 연구자, 망 사업자 등으로 구성된 개방된 공동체.
○ PDF (Portable Document Format)： 원본 문서가 어떠한 애플리케이션에서 작성되었는지에 상관없이 여러 플랫폼 환경에서 문서를 동일하게 출력하고 디스플레이할 수 있도록 해주는 파일 포맷. 미국 어도비사가 개발하여 전자 문서의 사실상 표준(de facto standard)으로 자리 잡아 오다가 2008년 국제 표준화 기구 국제 표준(ISO 32000-1)으로 채택되었다.
6. 인용표준
본 기술규격은 다음의 국내ㆍ외 기술규격 및 표준을 참조한다.
○ IETF RFC 3852 Cryptographic Message Syntax (CMS), 2004. 07.
○ IETF RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), 2001. 08.
○ IETF RFC 2634 Enhanced Security Services for S/MIME, 1999. 06.
○ IETF RFC 5035 Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility, 2007. 08.
○ IETF RFC 5816 ESSCertIDv2 Update for RFC 3161, 2010. 03.
○ ISO 32000-1 : 2008 Document management - Portable document format - Part 1: PDF 1.7, 2008. 07.
제2장 전자문서 진본확인 서비스 개요
2.1 전자문서 진본확인 서비스 프로세스
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
<그림 1> 정부시점확인 절차 및 기술규격 정의 범위
① 업무시스템 전자문서 확보： 행정기관의 업무시스템은 진본확인마크를 적용하기 위한 대상 전자문서(PDF)를 확보한다.
② 전자문서(PDF) 내 진본확인마크 등 부가정보 주입： 대상 전자문서(PDF) 내에 진본확인 마크 인영 등 시점확인(Time Stamp) 토큰 검증 및 확인에 필요한 부가정보를 주입한다.
③ 시점확인 요청 메시지 생성 : ②번의 결과에 대한 전자문서(PDF)를 기반으로 시점확인 요청 메시지를 생성한다.
④ 시점확인 요청 메시지 송신： 시점확인 요청 메시지를 송ㆍ수신 규격에 따라 정부 진본확인센터(GTSA)에 전송한다.
⑤ 시점확인 응답 메시지 수신： 송수신 규격에 따라 GTSA에서 시점확인 응답 메시지를 수신한다.
⑥ 시점확인 응답 메시지 처리： 시점확인 응답 메시지를 확인하고 시점확인 토큰을 추출하여 검증한다.
⑦ 전자문서(PDF) 내 시점확인 토큰 임베딩： 진본확인 마크 적용대상 전자문서(PDF)에 시점확인 토큰을 삽입한다.
⑧ 진본확인마크가 적용된 전자문서(PDF) 배포： 업무시스템에서 진본확인마크가 적용된 전자문서(PDF)를 이용자에게 배포한다.
⑨ 진본확인마크가 적용된 전자문서(PDF)의 시점확인 토큰 등 검증： 검증자는 검증 프로그램을 통하여 진본확인마크가 적용된 전자문서(PDF)의 시점확인 토큰을 추출하여, 진본여부를 검증한다.
⑩ 진본확인서비스 검증결과 육안확인： 검증 프로그램은 시점확인 토큰 검증결과에 대한 육안확인 정보를 진본확인마크로 표시한다.
2.2 기술규격 구성
본 기술규격은 업무시스템에서의 전자문서(PDF)의 진본확인 서비스를 위한 세부내용을 다음과 같이 정의하며 구성한다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
제3장 시점확인 메시지 기술규격
3.1 시점확인 요청 메시지
3.1.1 시점확인 요청 메시지 구성
시점확인 요청 메시지는 시점확인 국제규격(RFC3161) 따라 생성된 시점확인 요청 메시지(TimeStampReq) 데이터를 행정전자서명(GPKI) 인증서로 RFC3852의 SignedData 구조에 따라 전자서명하여 생성한다.
3.1.2 시점확인 요청 메시지 SignedData 구조
시점확인 요청 메시지는 RFC3852의 SignedData 구조를 준용하여 전자서명하며 다음의 프로파일을 따른다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
1) CMS Version： RFC3852의 기준에 따라 Version 1로 명시한다.
2) DigestAlgorithm： 전자서명에 사용한 알고리즘 OID를 명시한다. 본 기술규격에서는 해시 알고리즘은 SHA256의 사용을 권고한다.
3) ContentType： content 필드에 적용되는 데이터의 유형 OID를 명시한다. 본 기술규격에서는 id-data를 사용한다.
4) content： RFC3161에 따라 생성된 Request 데이터를 넣는다.
5) certificates： 전자서명에 사용된 인증서 또는 인증경로 상의 인증서들을 넣는다. 본 필드에는 전자서명에 사용된 인증서만 넣는다.
6) crls： 전자서명에 사용된 인증서 또는 인증경로 상의 인증서들에 대한 상태확인을 할 수 있는 CRL을 넣는다. 본 필드는 사용하지 않는다.
7) SignerInfos： 전자서명결과 및 전자서명에 사용한 인증서 정보를 넣는다. 본 기술규격에서는 요청기관 하나의 전자서명만을 정의한다. signedAttrs 하위 필드는 ContentTyep과 MessageDigest 속성을 포함한다.
3.1.3 시점확인 요청 RFC3161 TimeStampReq 구조
전자서명 대상 데이터는 RFC3161의 TimeStampReq 구조를 준용하며 다음의 프로파일을 따른다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
1) version： RFC3161에 따라 Version 1로 명시한다.
2) hashAlgorithm： 전자문서(PDF) 해시에 사용된 알고리즘을 명시한다. 본 기술규격에서는 SHA256 또는 SHA512을 사용한다.
3) hashedMessage： 전자문서 PDF를 해시한 결과를 넣는다.
4) reqPolicy： 시점확인 정책에 대한 OID값을 명시하며, GTSA에서 배포하는 정책을 준용하여 사용한다.
5) nonce： 8바이트 이상의 난수를 넣는다.
6) certReq： 응답메시지에 GTSA 인증서 정보가 포함되어야 하는지에 대한 요청을 True 또는 False로 명시한다. 기본값으로 False를 사용하며, True를 사용하는 경우 반드시 응답메시지의 SignerInfos 필드 내 signedAttrs 하위 필드가 SigningCertificate 속성 또는 SigningCertificateV2 속성을 포함하여야 한다.
7) extensions： 부가적인 정보를 명시할 수 있으나, 본 기술규격에서는 본 필드를 사용하지 않는다.
3.2 시점확인 응답 메시지
3.2.1 시점확인 응답 메시지 구성
시점확인 응답 메시지는 RFC3161에 따라 생성된 TimeStampResp 구조에 따라 생성한다.
3.2.2 시점확인 응답 RFC3161 TimeStampResp 구조
시점확인 응답 메시지는 RFC3161의 TimeStampResp 구조를 준용하여 다음의 프로파일을 따른다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
1) status： RFC3161에 정의된 처리 결과를 준용한다.
2) TimeStampToken： 전자문서(PDF)에 대한 시점확인 토큰 값을 넣는다. RFC3161에 따라 처리 결과가 성공인 경우에만 포함한다.
3.2.3 시점확인 토큰 RFC3161 TimeStampToken 구조
시점확인 토큰은 RFC3161의 TimeStampToken 구조를 준용하며 다음의 프로파일을 따른다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
1) contentType： content 필드에 적용되는 데이터의 유형 OID를 명시한다. 본 기술규격에서는 id-signedData를 사용한다.
2) version： RFC3852에 따라 CMS 버전을 명시한다.
2) digestAlgorithm： 전자서명에 사용한 알고리즘 OID를 명시한다. 본 기술규격에서는 해시 알고리즘은 SHA256 또는 SHA512를 사용한다.
3) TSTInfo： RFC3161에서 정의한 TSTInfo 구조를 준용한다. 본 기술규격에서는 3.2.4에서 정의한 TSTInfo 구성방식을 따른다.
4) certificates： 전자서명에 사용된 인증서 또는 인증경로 상의 인증서들을 넣는다. 본 필드에는 시점확인 토큰 전자서명에 사용된 인증서는 필수이다
5) crls： 전자서명에 사용된 인증서 또는 인증경로 상의 인증서들에 대한 상태확인을 할 수 있는 CRL을 넣는다. 본 필드는 사용하지 않는다.
6) SignerInfos： 전자서명 결과 및 전자서명에 사용한 인증서 정보를 넣는다. 본 기술규격에서는 발급기관의 전자서명만 포함하는 것을 정의한다. signedAttrs 하위 필드는 ContentType과 MessageDigest 속성을 포함하며, 시점확인 요청 메시지 내 Request 데이터의 certReq 필드값이 True 인 경우에는 SigningCertificate 또는 SigningCertificateV2 속성을 포함한다. SigningCertificate 또는 SigningCertificateV2 속성에는 certificates 필드에 포함된 인증서 각각에 대한 정보를 RFC2634 또는 RFC5816에 따라 명시한다.
3.2.4 시점확인 정보 RFC3161 TSTInfo 구조
시점확인 정보는 RFC3161의 TSTInfo 구조를 준용하며 다음 프로파일을 따른다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
1) contentType： content 필드에 적용되는 데이터의 유형 OID를 명시한다. 본 기술규격에서는 id-ct-TSTInfo를 사용한다.
2) version： RFC3161에 따라 버전을 명시한다. 본 기술규격에서는 Version 1을 사용한다.
3) policy： 시점확인 정책에 대한 OID를 명시한다. 시점확인 OID는 시점확인 토큰을 발급하는 기관의 정책을 따른다.
4) messageImprint： 전자문서(PDF)를 해시하는데 사용한 알고리즘 및 해시값을 명시한다. 해시 알고리즘은 SHA256 또는 SHA512를 사용한다.
5) serialNumber： 시점확인 토큰에 대한 일련번호를 명시한다.
6) genTime： 시점확인 토큰이 생성된 시각을 명시한다. 본 기술규격에서는 시각정보를 GeneralizedTime 형식으로 명시한다.
7) accuracy： 시점확인 시각에 대한 오차범위를 명시한다.
8) ordering： 발급된 시점확인 토큰의 시각에 따른 발급순서 결정방식을 명시한다.
9) nonce： 시점확인 요청 메시지에 포한된 난수값과 동일한 값을 넣는다. 본 기술규격에서는 nonce 필드의 사용을 필수로 정의한다.
10) tsa： 시점확인 토큰을 발급하는 기관의 인증서의 소유자 DN을 명시한다. 본 필드의 값은 시점확인 토큰 생성을 위하여 사용된 인증서의 SubjectDN 필드의 값과 동일해야 한다.
11) extensions： 시점확인 토큰과 관련된 부가정보를 명시한다. 본 기술규격에서는 부가정보를 정의하지 않는다.
제4장 송ㆍ수신 기술규격
시점확인 요청 및 응답 메시지의 송ㆍ수신을 위하여 다양한 전송방식이 사용될 수 있으며, 본 기술규격에서는 HTTP 기반의 송수신을 정의한다.
4.1 HTTP 기반 송ㆍ수신 방식
HTTP 기반에서 시점확인 요청 및 응답 메시지는 MIME 객체로 취급하여 전송하며, MIME 처리되는 시점확인 요청 및 응답 메시지는 DER 인코딩된 형태이어야 한다.
4.2 기타 송ㆍ수신 방식
시점확인 요청 및 응답 메시지 전송을 위한 다른 방식에 대해서는 본 기술규격에서 정의하지 않으며, 필요 시 기술규격 개정을 통하여 추가한다.
제5장 전자문서(PDF) 내 시점확인 토큰 적용ㆍ검증 기술규격
5.1 전자문서(PDF) 내 시점확인 토큰 적용
전자문서(PDF)에 대한 시점확인 토큰을 적용하기 위하여 ISO 32000-1을 준용하며 다음을 수행한다.
ㆍ 전자문서(PDF) 해시
ㆍ해시값 기반 시점확인 토큰 획득
ㆍ전자문서(PDF) 내에 시점확인 토큰 주입
5.1.1 전자문서(PDF) 해시
전자문서(PDF)의 해시는 <그림 2>와 같이 지정된 부분을 읽어 들여 해시를 수행하고 해시 값을 생성할 수 있어야 한다. 해시알고리즘은 SHA256 또는 SHA512를 사용한다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
전자문서(PDF)의 해시영역은 /ByteRange[숫자쌍의 배열]로 나타내며, 해시값 생성 한 구간마다 하나의 숫자쌍(Offset시작바이트, 바이트 길이)으로 표현한다. <그림2>와 같이 /Contents 엔트리 내 시점확인 토큰이 저장되어야 하는 영역은 해시영역에서 제외하고 엔트리 구조는 [표 7]과 같다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
해시영역에서 제외되는 ByteRange 범위 이외의 영역에 대해서는 검증 시 별도의 무결성 보장 방안을 제시하여야 한다.
5.1.2 시점확인 토큰 획득
5.1.1에서 획득한 해시값을 기반으로 GTSA로부터 시점확인 응답 메시지를 획득한다.
획득한 시점확인 응답 메시지로부터 TimeStampToken 필드를 추출하여 시점확인 토큰을 획득한다.
5.1.3 전자문서(PDF) 내 시점확인 토큰 주입
시점확인 토큰 주입을 위한 Filter 엔트리명은 ‘Government Timestamp’로 한다. 5.1.2에서 획득한 시점확인 토큰을 5.1.1에서 지정한 /Contents 엔트리 내에 주입한다. DER 인코딩된 시점확인 토큰을 16진수 형태의 텍스트로 표현하여 저장한다. 예를 들어 0x3082 2바이트 값을 ‘3082’ 4바이트 문자열로 저장한다. /Contents 엔트리 내에는 시점확인 토큰 이외의 값은 ‘0’으로 채워져야 한다.
5.2 전자문서(PDF) 내 시점확인 토큰 검증
전자문서(PDF)에 적용된 시점확인 토큰 검증을 위하여 ISO 32000-1을 준용하며 다음을 수행한다.
ㆍ 전자문서(PDF) 내 시점확인 토큰 추출
ㆍ 시점확인 토큰 전자서명 및 인증서 검증
ㆍ 전자문서(PDF) 해시 및 무결성 확인
5.2.1 전자문서(PDF) 내 시점확인 토큰 추출
‘Government Timestamp’값을 갖는 Filter 엔트리를 찾아 /Contents 엔트리의 값에서 시점확인 토큰을 추출한다.
5.2.2 시점확인 토큰 전자서명 검증 및 인증서 검증
시점확인 토큰은 RFC3852을 준용하여 전자서명 값을 검증하고 이에 사용된 인증서 및 인증경로를 검증한다.
5.2.3 전자문서(PDF) 해시 및 무결성 확인
/ByteRange 엔트리에서 지정한 영역을 추출하여 해시값을 계산한다. 해시알고리즘은 시점확인 토큰 내 TSTInfo 하위필드 중 messageImprint 부분에서 지정하고 있는 알고리즘을 사용하며 계산된 해시값과 시점확인 토큰 내 TSTInfo 하위필드 messageImprint 부분에 포함되어 있는 해시값이 동일한 지 여부를 비교하여 전자문서(PDF)의 무결성을 확인한다.
제6장 진본확인 마크 기술규격
PDF 열람기를 이용하여 진본확인마크가 적용된 전자문서(PDF)의 내용을 이용자 단말기의 화면으로 열람하는 경우, PDF 열람기는 열람 즉시 시점확인 토큰을 검증하고 결과에 적합한 진본확인마크를 화면에 표시하여야 한다.
검증 결과에 따른 진본확인마크를 전자문서(PDF)에 적용하고 화면에 표시하기 위하여 ISO 32000-1을 준용한다.
6.1 시점확인 토큰 검증 상태 구분
시점확인 토큰 검증 결과에 따른 상태는 다음과 같은 확인방식에 따라 구분한다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
① 시점확인 토큰의 전자서명 검증에 실패하는 경우 ‘변조’ 처리
② 시점확인 토큰의 전자서명에 사용된 인증서 및 인증경로 검증에 실패하는 경우 ‘인증서 검증 실패’처리
③ 전자문서(PDF)의 해시값과 시점확인 토큰 내 해시값이 동일하지 않은 경우 ‘변조’ 처리
④ 모든 검증 결과가 성공인 경우 ‘진본’ 처리
PDF 열람기가 본 규격에 따라 검증이 불가능한 경우를 위하여 ‘미검증’ 상태를 추가로 정의하고, ‘변조’와 ‘인증서 검증 실패’ 두가지 상태가 동시에 나오는 경우는 중요성을 감안하여 ‘변조’를 표시한다.
6.2 진본확인마크 이미지 구성
진본확인마크 이미지는 정부진본확인센터 배경이미지, 시점확인 토큰 시각정보, 검증상태 정보를 포함하여야 한다. 진본확인마크 이미지는 본 기술규격에서 정의하지 않으며, 정부진본확인센터(GTSA)에서 별도 정의한 상세규격을 따른다.
〔별표·서식 이미지 — 상단 '원문 보기'에서 확인〕
</img>
제7장 재검토 기한행정안전부 장관은 「훈령ㆍ예규 등의 발령 및 관리에 관한 규정」에 따라 이 고시에 대하여 2022년 7월 1일 기준으로 매 2년이 되는 시점(매 2년째의 6월 30일까지를 말한다)마다 그 타당성을 검토하여 개선 등의 조치를 하여야 한다.