Introduction to Code Signing

ClickOnce의 배포를 이야기하면서 Authenticode에 대한 이야기가 나와서 그 원리를 함 알아보려고 했다. 달봉이도 Authenticode에 대해서는 잘 모른다. 혹시라도 잘못된 곳이 있으면 사정없는 댓글에 대한 희망을 전한다.

---

Introduction to Code Signing 요약

■ 코드 사인(code singing) 소개

인터넷으로 파일 다운로드하는 경우, 두 종류의 보안 이슈가 발생한다.

1. 게시자의 신뢰성 확인(Ensuring authenticity)
- 누가 게시했나? 즉 게시한 사람은 믿을 수 있나?
2. 코드의 무결성 확인(Ensuring integrity)
- 게시 이후 코드(소프트웨어)는 변경되지 않았나?

Authenticode는 이런 이슈를 해결하기 위한 Microsoft에서 제시한 솔루션을 말한다.

■ Authenticode

Authenticode 자체는 사인이 된 코드를 만들어 내지 않는다. 단지 코드 사용자들에게 코드 게시자(publishers)가 신뢰할 수 있는 인증 기관의 인증을 받았는가를 알려줄 수 있는 메커니즘이다. Authenticode는 인터넷을 이용한 코드(소프트웨어)의 배포 및 다운로드에 참여하고 있는 코드 게시자 및 코드 사용자 모두에게 필요한 기술이다.

■ 코드의 변경 여부 확인- 디지털 사인(Digital Signatures) 

코드(데이터 또는 소프트웨어)를 배포할 때 사용자들에게 배포자가 누구인지를 알리고 싶을 때 사용하는 것이 디지털 사인이다. 디지털 사인은 데이터의 내용을 변경하지 않는다. 다만 데이터와 함께 배포될 수 있는 디지털 사인 문자열이 생성된다. 이 디지털 문자열과 데이터가 한 파일로 묶여서 배포될 수 있다.

디지털 서명은 "public-key 알고리듬"을 사용해서 생성된다. 이 알고리듬은 이름과는 달리 public / private 키 쌍을 사용한다.
Authenticode 기술에서는 private 키를 "서명"에 사용하고, 다시 "서명의 확인"에 public 키를 사용하게 된다. ( 이 한줄은 기본이 되어 있지 않은 달봉이를 끝까지 인내로서 대해주신 정성태님의 지극한 조언이 없었으면 나오지 못했을 말이다. 근데 잘 이해를 했는지는 모르겠다.  쯔읍 아휴~~허접덩이)

public-key 알고리듬을 응용한 Authenticode 서명(-_-;;) 데이터 소유자는 데이터를 public / private 키를 생성해서, public 키는 필요한 모든 사람들에게 공개한다. 특정 private 키로 서명을 하면 서명확인은 반드시 해당 public 키로 해야 한다.

Authenticode 의 프로세스를 요약하면 다음과 같다.
1. 파일의 해시(one-way hash)값을 계산한다.
2. 해시값은 private 키를 이용해서 암호화가 된 문자열(서명 문자열)을 만들어낸다.
3. 파일과 서명이 된 해시값, public 키를 배포한다.
4. 배포를 받은 클라이언트는 파일의 해시값을 구한다.
5. 클라이언트는 사인이 된 해시값을 public 키를 이용해서 다시 복호화해서 원래의 해시값을 구한다.
6. 클라이언트가 구한 두 해시값이 일치하면 코드는 배포 이후에 변경되지 않았다는 것을 알 수 있다.

■ 게시자의 신뢰여부 확인 - 인증서(Digital Certificates)

디지털 인증서(digital certificate)는 라는 것은 적절한 절차를 거쳐 신청자(게시자)의 신청을 심사한 후 인증 기관(Certification Authority, CA)이 발행한다. 실제의 디지털 인증서는 파일로 존재하는데, 이 파일의 구조에는 신청자 및 인증 기관에 대한 정보 등 여러 가지가 포함되어 있다. 다음 그림은 X.509 프로토콜의 인증서 구조를 나타내고 있다.

X.509타입의 인증서 구조

Version : 인증서 포맷을 규정하는 번호
Serial Number : CA의 고유한 번호
Algorithm Identifier : 인증서를 서명하기 위해서 사용된 알고리듬
Issuer : CA 명
Period of Validity : 인증서의 유효 기간 정보
Subject : 신청자명
Subject’s Public Key : 신청자의 public 키 정보
Signature : CA의 디지털 서명

디지털 인증서는 크게 신청자의 “신청정보”와 “인증 기관의 디지털 서명”으로 구성되어 있다. 인증 기관의 디지털 서명은 인증 기관의 private 키로 “신청정보”를 암호화한 문자열이다. 인증서를 사용하는 클라이언트측에서는 이 인증기관의 디지털 서명과 인증기관의 public 키를 이용하면, 인증서에 포함된 게시자의 public 키가 인증 기관이 인증서를 발행했던 그 신청자의 public 키인지를 확인할 수 있다.

인증서에 포함된 신청자의 public 키 검증
(클릭을 하면 선명한 화면이 보입니다.)

그림은 인증서에 포함된 신청자의 public 키가 실제로 인증 기관이 인증한 신청자의 public 키인지를 검증하는 프로세스를 그린 것이다. 점선 부분이 인증서를 사용하는 클라이언트측에서 수행되는 검증 작업을 나타낸다. 만약 신청자의 public 키를 포함하고 있는 “신청정보”의 해시값과 인증서에 포함된 인증기관의 서명과 인증기관의 public 키로 복호화된 해시값이 일치하면 신청 정보가 변경되지 않았다는 것이고 따라서 신청 정보에 포함된 신청자의 public 키도 변경되지 않았다는 것을 알 수 있다. 이것은 또한 디지털 인증서의 가장 중요한 목적중의 하나인 인증서에 포함된 게시자는 인증 기관의 인증을 받은 것으로 판단내릴 수 근거가 될 수 있다. 즉 인증서의 게시자를 신뢰할 수 있게 되는 근거가 될 수 있다.   

■ 정리

이제 정리를 하자면 다음 두 그림으로 요약될 수 있다.

서명 과정

이 그림은 게시자(인증서 소유자)가 파일(어셈블리 파일)에 서명을 하는 과정을 나타내고 있다. 그림을 보면 파일의 해시값(정확히는 파일 전체의 해시값이 아니라 “메시지 축약(message digest)에 대한 해시값)을 게시자의 private 키로 서명을 한다. 그리고 시그너쳐 문자열과 인증 기관으로부터 발급받은 디지털 인증서를 서명 툴들을 사용하면 최종적으로 원래의 파일 내용의 검증 작업에 필요한 정보들이 덧붙여진 모습의 파일이 그림처럼 생긴다. 이제 이 파일을 인터넷을 통해서 사용자들에게 배포하면 된다.

서명확인 과정

인터넷을 통해서 배포받은 파일에 대해서 클라이언트(브라우저)측에서 검증하는 절차를 나타내고 있다. 클라이언트측에서는 먼저 원래 파일의 데이터를 이용해서 계산한 해시값과 게시자의 public 키를 사용해서 복호화한 해시값을 비교해서 코드의 무결성을 검증한다. 코드 무결성 검증을 통과하면 인증서가 신뢰할 수 있는 기관에서 발행한 것인지를 확인하는 작업을 하게 된다. 이 모든 작업을 통과하면 파일은 게시 이후에 변경되지 않았고 또한 인증기관의 인증을 받은 신뢰할 수 있는 게시자가 그 파일을 배포했다는 것을 의미하게 된다.

---

참조문서

Introduction to Code Signing - msdn
http://msdn.microsoft.com/library/default.asp?url=/workshop/security/authcode/intro_authenticode.asp