인증서와 인증서를 이용한 코드 사인의 해시 구분
간혹 이걸 헷갈리는 분이 있어서 설명을 해봅니다. ^^
가령, 여러분이 Verisign을 통해 인증서를 받았다고 가정해 보겠습니다. 그렇게 해서 받은 여러분의 인증서는 Verisign의 개인키로 서명된 해시 값을 포함하고 있습니다. 해시 알고리즘으로는 MD5, SHA1, SHA2,... 등이 있겠지요.
그리고, 여러분이 받은 인증서로 "코드 서명"한 파일(EXE, DLL, ...)의 경우 인증서 자체의 해시 방법에 상관없이 또 다른 해시 알고리즘을 이용한 해시가 가능합니다. 즉, 해시 생성은 여러 해시 알고리즘 중의 하나를 사용하면 되고, 그것을 여러분들의 인증서에 포함된 개인키로 암호화하면 되기 때문입니다. 따라서 루트 인증기관으로부터 받은 인증서의 해시 값은 이런 경우 영향을 줄 수 없습니다. (사실, 당연한 이야기입니다.)
말로만 하면 재미없으니까, ^^ 실제로 사례를 보겠습니다.
다음은 제니퍼소프트의 코드 사인에 사용하는 인증서를 인증서 관리자의 속성 창을 통해 본 것입니다.
화면에서 보여지듯이 루트 인증 기관에 의해 해당 인증서가 sha256(Signature hash algorithm)으로 해시되었고 그 해시된 내용을 RSA(Signature algorithm)의 개인키에 의해 암호화(이럴 때는 서명)되었음을 보여줍니다. 이를 검증하는 측에서는 미리 설치된 루트 인증 기관의 인증서에 담긴 '공캐키'로 복호화하고 그 값을 현재 인증서의 내용을 sha256으로 다시 해시한 값과 비교해서 위변조 여부를 판별하게 됩니다.
위의 코드 서명용 인증서로 다시 다른 응용 프로그램을 서명하는 데에는 별개의 작업이 됩니다. 즉, 다음과 같이 서명을 하면 SHA1 알고리즘을 사용한 해시값을 생성해 여러분들 소유의 인증서에 포함된 개인키로 서명한 것이고,
signtool sign /v /sm /n "...[이름]..." /t ...[timestamp_server_url]... c:\temp\MyTest.exe
이렇게 서명된 MyTest.exe를 윈도우의 속성창으로 보면 다음과 같이 해시 알고리즘을 확인할 수 있습니다.
혹은, 다음과 같이 서명을 하면 SHA2 알고리즘을 이용해 서명한 해시값이 대상 파일에 첨부됩니다.
signtool sign /fd SHA256 /v /sm /n "...[이름]..." /tr ...[timestamp_server_url]... c:\temp\MyTest.exe
역시 속성창을 통해 다음과 같이 확인할 수 있습니다.
이어서, 인증서의 속성창에 보이는 2개의 hash 값을 살펴볼까요?
왼쪽 화면에서 보이는 해시는 인증서의 유효성을 검증하는 데 사용하는 값인 반면 thumbprint 값은 인증서 자체에 포함된 내용은 아니고 인증서를 식별하기 위해 해당 인증서 자체를 hash한 값입니다. thumbprint 값이 의미가 있는 것은, 해당 인증서를 선택하도록 구분하는 데 있습니다. 가령 인증서 저장소에 있는 많은 인증서 중에는 이름이 같은 경우도 있는데요, 그런 경우 그 중의 하나를 선택하기 위해 해당 인증서의 thumbprint 필드의 값으로 지정할 수 있습니다. 보다 자세한 사항은 다음의 글을 보시면 한 눈에 파악할 수 있습니다.
Understanding X.509 digital certificate thumbprints
; http://morgansimonsen.com/2013/04/16/understanding-x-509-digital-certificate-thumbprints/
따라서, 인증서의 내용을 해시해서 사용하는 값이기 때문에 인증서의 어떠한 내용이라도 변경되면 thumbprint 값이 바뀌게 됩니다. 즉, 인증서 재발급을 한 경우에도 바뀌게 되는데 이때 코드에서 해당 인증서를 식별하기 위해 thumbprint로 지정했다면 문제가 발생하게 됩니다. 그래서, 가능하면 인증서 지정은 thumbprint보다는 Subject 필드 이름으로 구별하는 것이 좋습니다.
기왕 알아본 김에 또 다른 hash 값도 살펴보겠습니다. 이 값도 인증서 자체에는 포함되지 않는 값인데, 코드 서명을 하는 경우 지정하는 timestamp 정보와 그것의 유효성을 검증할 수 있도록 해당 타임스탬프를 발행하는 서버에서 사용하는 hash가 있습니다. 이 값을 확인하려면 코드 서명된 파일의 속성창에서 "Digital Signatures"를 통해 다음과 같이 복잡하게 들어가야 합니다.
Verisign의 경우 sha1 해시의 타임스탬프를 얻으려면 /t 옵션과 함께 다음의 url을 설정하고,
signtool sign /v /sm /n "...[이름]..." /t http://timestamp.verisign.com/scripts/timestamp.dll c:\temp\MyTest.exe
sha256 해시의 타임스탬프를 얻으려면 /tr 옵션과 함께 다음의 url을 지정해야 합니다.
signtool sign /v /sm /n "...[이름]..." /tr http://timestamp.geotrust.com/tsa c:\temp\MyTest.exe
그런데, 이유는 알 수 없지만 해당 타임스탬프가 sha256으로 해시되었는지에 대해서는 속성 창을 통해 들어가봐도 동일하게 sha1이라고 나옵니다. 현재 timestamp 서버 측에서 지원을 안하는 것인지? 아니면 UI상에서 sha1으로만 나오게 되는 것인지? 의문입니다.
여담을 하나 추가하자면. ^^
(제니퍼 5에서는 바뀌었지만) 제니퍼 4 제품의 경우, 클라이언트 측의 동적 화면을 구현하기 위해 JAVA applet이 사용되었는데요. 이 애플릿이 Verisign으로부터 받은 인증서로 서명되어 배포됩니다.
그런데, 다음의 URL과 함께 고객사로부터 질문이 왔는데요.
Windows Enforcement of Authenticode Code Signing and Timestamping (2015년 9월 24일에 배포되었습니다.)
; http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx
이로 인해 SHA1 해시로 서명된 자바 애플릿이 사용 불능이 되는 것 아니냐는 것이었습니다.
차근차근 생각해 보면, 이에 대한 답을 알 수 있습니다. 일단 윈도우의 코드 서명은 윈도우의 서명 규칙을 따른 경우에 적용되는 것으로 현재 ActiveX나 Kernel 디바이스 드라이버로 사용되는 파일이 이에 해당합니다. 반면 자바 애플릿 코드를 담은 파일(.class, .jar) 자체는 윈도우의 코드 서명 대상이 아닙니다. Internet Explorer는 "자바 애플릿"을 활성화 해주는 "컨테이너 역할을 하는 ActiveX"가 윈도우의 코드 서명이 되었는지를 검증할 뿐입니다. 해당 ActiveX는 오라클에 의해 배포되는 자바 런타임에 포함된 CLSID == 8AD9C840-044E-11D1-B3E9-00805F499D93의 ActiveX(C:\Program Files\Java\jre1.8.0_40\bin\jp2iexp.dll)를 로드합니다. 즉, jp2iexp.dll 파일이 정상적으로 서명되었는지를 윈도우는 검증하는 것입니다.
이후 jp2iexp.dll에서 "jp2launcher.exe" 프로세스가 생성되고 그 안에서 JAVA Applet이 (%userprofile%\appdata\LocalLow\Sun\Java\Deployment\cache\...)와 같은 폴더로 복사된 후 활성화됩니다. 여기서 중요한 점은, 사용자가 코드 서명한 java applet의 검증은 윈도우가 아닌 오라클이 만든 jp2launcher(또는 jp2iexp.dll)에 의해 된다는 것입니다.
따라서, 애플릿 서명을 어떻게 했든 윈도우 정책과는 무관한 것입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]