SHA1 알고리즘 취약점 발견으로 SHA1기반의 인증서 업그레이드가 권고되고 있다. 이에 필요한 관련 기술 및 작업 절차에 대한 정리이다.

1. SHA-2 기반 인증서 업그레이드 이해
황인균
2016.01.08

2. 1. SHA-1 이슈
SHA 패밀리(Secure Hash Algorithm)는 “메시지 인증” 그리고 “전자 서명” 등에 사용되는 해시
알고리즘중의 하나이다. “메시지 인증”이라 함은 “사용자 인증”과 유사하게 전달된 메시지가 원래의
메시지인지를 인증하는 기능을 말한다. SHA 같은 해시 알고리즘을 “메시지 인증”에 사용해서 메시지
전달 도중에 외부의 조작에 의해서 변경되었는지 확인할 수 있다.
이슈를 요약하면 다음과 같다.
“SHA-1에 취약성이 발견되어서 SHA-2로 업그레이드되어야 한다. 이로 인해서 “SHA-1 기반의 인증
서는 SHA-2 이상의 알고리즘을 사용하는 인증서로 업그레이드되어야 한다.
“SHA-1 기반 인증서”라 함은 “인증서 자체의 무결성 즉 인증서가 발급된 이후 외부로부터
수정되었는지 확인할 수 있는 알고리즘으로서 SHA-1 을 사용하고 있는 인증서”를 말한다.
SHA-1 에 대한 취약점의 좀 더 자세한 설명은 “메시지 무결성 확인” 절을 참조한다.
IT 기술의 보안 시나리오에서 메시지 무결성 확인과 관련된 엔터티 및 구조를 간략히 그려보면
다음과 같다.
참고로, SHA 에는 몇 가지 그룹의 버전이 있다 : SHA-0, SHA-1, SHA-2, SHA-3. 그리고 각 그룹에는
또 구체적인 버전이 있을 수 있다.
https://en.wikipedia.org/wiki/Secure_Hash_Algorithm
2. 업그레이드 체크 포인트
위 엔터티 위주의 개략도는 SHA-2 업그레이드와 관련해서 체크해봐야 하는 부분을 제시해준다.

3. ■ SSL 프로토콜 관점의 체크 포인트
SSL 프로토콜은 양방향 통신으로서 클라이언트 프로그램(주로 웹 브라우저, Internet Explorer)과 서버
프로그램( 웹 서버, IIS)에서 모두 SHA-2 가 지원되어야 한다.
현재 SHA-2 가 지원되고 있는 클라이언트와 웹 서버는 다음과 같다.
SHA-2 지원 클라이언트 SHA-2 지원 웹 서버
- Apple OS X : 10.5 이상
- Apple iOS : 3.0 이상
- Android : 2.3 이상
- Blackberry : 5.0 이상
- Windows : XP SP3 이상
- Windows Phone : 7 이상
- Chrome : 26 이상
- Firefox : 1.5 이상
- IE : 6 이상(OS가 XP SP3이상일
경우)
- Mozilla : 1.4 이상
- Netscape : 7.1 이상
- Opera : 9.0 이상
- Safari : 3 이상 (OS X의 경우 10.5이
상일 경우)
① [OpenSSL 기반] Linux Apahce 2.2.58 / Nginx /
Lighttpd /Webtob 4.1 & openssl 0.9.8a 이상
② [JAVA계열] Weblogic 10.3.1 /Tomcat/ regin/
Sunone/ iPlanet & Java 1.4.2 이상
③ IBM HTTP 7.0 / 8.0 & Websphere 7.0.0.2 /
8.0.0.7 이상
④ Window IIS 7.X 이상 (6.0 패치 적용 후)
⑤ Oracle Wallet Manager 11.2.0.1 이상
⑥ Lotus Domino 9+ 이상
클라이언트측 브라우저가 SHA-2를 지원하는지에
대한 테스트는 아래 링크에서 가능하다.
https://ssltest39.ssl.symclab.com/
■ 인증서 기반 관점의 체크 포인트
그리고 “인증서 기반의 보안 구조”에서는 “인증서의 유효성 체크”가 필요한데 이것을 위해서는 인증
기관(중개 기관)의 사전 준비도 필요하다.
인증 기관 및 중개 기관에서의 SHA-2 지원 여부는 인증서 구매 업체를 통해서 하는 것이 편하다.
이때 기업의 모든 시스템이 일괄적으로 SHA-1 에서 SHA-2 로 갈 것이 아니라면 SHA-1, SHA-2 병행
지원 여부도 문의해 볼 필요가 있을 것으로 보인다.

4. 3. 작업 절차
SHA-1 이슈와 관련해서 문제는 SHA-1 알고리즘은 코드 인증, SSL 통신 등을 비롯해서 다양한 보안
아키텍처에서 사용되고 있다는 것이다. 기업에서 사용하고 있는 “SHA-1 기반 인증서”를 “SHA-2”로
변경하는 작업에는 많은 주변 환경의 지원이 필요하다. 기업에서의 작업 절차를 정리해 보면 다음과
유사하게 될 것 같다.
1) 현재 중개 기관( 예, UCERT, CERTKOREA)는 SHA-1, SHA-2 기반의 인증서( SSL인증서, 코드사인 인
증서)를 병행 지원하도록 구성이 완료됨.
( * 중개기관만 지원된다면, 루트 CA의 지원 상황은 기업의 업그레이드와는 무관할 것으로 판단)
2) 최소한 2016.06월 이전까지는 모두 SHA-2 기반으로 전환하는 것이 바람직할 것으로 판단.
3) codesign 인증서 업그레이드
- 현재 상용 컨트롤, ActiveX, 드라이버 등 3rd
파티 제품, 솔루션을 조사
- 각 업체별로 codesign 인증서를 사용하는지, SHA-2 업그레이드 영향도 없는지 확인 필요.
4) SSL 인증서 업그레이드
- SSL 인증서 사용 제품, NW, 보안장비, 개발S/W 등 목록을 조사.
- 각 업체별로 SSL 인증서를 사용하는지, SHA-2 업그레이드 영향도 없는지 확인 필요.
- 작업은 서버별로 점차적으로 업그레이드 진행해 갈 수 있다.
이런 작업은 아래의 주요 벤더 및 업체들의 일정을 고려해서 진행되어야 할 것이다.
4. SHA 변경 관련 주요 정책 일정
일반 기업에서는 주요 일정 및 작업 절차를 확인해서 정리하는 것이 바람직하다. 기업에서 거래하고
있는 인증서 판매 업체를 통해서 확인해보는 것도 좋을 것으로 보인다. 다음은 마이크로소프트
플랫폼을 사용하고 있는 기업에서의 일정 정리의 예시이다.
벤더 주요 일정 주요 정책 소프트웨어 비고
마이크로소프트 2016.01.01
1) SHA-1 기반 코드 인증
서비스 일부 중지
2) CA*는 SHA-2 기반 TLS
인증 서비스 지원 권고
* CA : Global Code Sign,
Windows 7
이상
2016.01.01 이후의
타임스탬프 값을 갖는
SHA-1 기반 코드
사인은 신뢰하지 않게
됨.

5. Thawate 등
마이크로소프트 2016.06.01
SHA-1 인증서를 사용하는
경우, 프로세스에 "Speed
bump" 삽입 계획 중.
Windows 7
이상
경고(Speed bump)만
출력되고 계속
프로세스가 진행될지는
확인 못함.
마이크로소프트 2017.01.01
SHA-1 기반 SSL 인증
서비스 완전 중지
Windows 7
이상
인증서 UCERT 2016.01.01
SHA-1 기반 SSL 인증서
발급 중지
UCERT
(인증서 판매
업체)
현재
(2016.01.06)
SHA-2 기반 인증 서비스
지원
CERTKOREA
(인증서 판매
업체)
현재
(2016.01.06)
SHA-2 기반 인증 서비스
지원
서버별로 SHA-1, SHA-2
적용 가능. SHA-2
인증서로
업그레이드하는 경우는
중개 인증서도 SHA-2 로
업그레이드해야 한다.
참고)
1) http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-
authenticode-code-signing-and-timestamping.aspx
2) https://www.ucert.co.kr/ssl/algorithm-change.html
3) http://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=23883
위 일정대로라면 최소한 2016.06 월 이전까지는 업그레이드 작업이 완료되는 것이 안전할 것으로
보인다.

6. 5. 부록 1. 인증서 기반 보안 개요
공개키 인증서 기반 즉 PKI 기반의 구조에 대한 이해는 SHA 인증서 업그레이드 작업에 좀 더 많은
도움이 될 것으로 보인다.
5.1 메시지 무결성 확인
“메시지 인증”은 메시지가 외부로부터의 수정이 있었는지에 대한 확인을 할 수 있는 기능이다. 이
기능은 여러 가지 시나리오에서 사용되고 있다. 예를 들면, 코드 변경 여부를 확인하는
시나리오( 코드 인증) 그리고 클라이언트, 서버간의 통신을 안전하기 위한 시나리오(SSL 통신) 등이
있다. 또한 소위 공개 기반 구조(PKI)에서도 사용된다. PKI 기반 구조에서는 “공개키”는 인증서를
통해서 배포되어 비대칭 암호화(RSA 같은)에 사용된다. 이때 인증서의 공개키가 외부에 의해서
변경되었는지도 확인해야 하는데, 공개키 유효성을 체크하는데도 SHA 같은 해시 알고리즘이
사용된다.
지금 문제가 되는 것은 ②번 단계에서 사용하고 있는 “SHA-1”의 취약으로 인해서 “메시지 원본”이
수정되어도 SHA-1 에 의해서 “계산된 해시 값”이 Sender 에서 보낸 “메시지 해시 값”과 같아질 수도
있다는 것이다.
5.2 인증서 흐름도
해시 알고리즘을 사용하는 보안 시나리오에 대한 예시 구조를 그려보면 “SHA2 로의 업그레이드”의
작업을 하기 위해서 “어느 부분을 확인해봐야 하는지”에 대한 이해에 도움이 될 수 있을 것으로
보인다.
일반 IT 환경에서 SSL 통신 및 코드 사인을 이용한 보안은 아주 흔한 시나리오이다. 이
시나리오에서도 해시 알고리즘을 사용하고 있다. 따라서 앞의 그림을 좀 더 자세히 확인해 보는
작업은 좀 더 도움이 될 것으로 보인다.

7. Client : 브라우저(Internet Explorer), 사용자
Server : 웹 서버(IIS)
CA : Certificate Authority, RA : Registration Authority
① 인증서 요청/발급
기업 IT 관리자는 인증기관 또는 중개 기관에 코드 인증서, SSL 인증서 등 필요한 종류의 인증서를
요청한다. 인증서 요청은 인증서 판대 대행 업체를 통해서 진행할 수 있다.
② 인증서 설치
기업의 IT 관리자는 서버에 SSL 인증서를 설치하거나 또는 제작한 코드( ActiveX, 드라이버 또는 실행
파일 등)를 제공받은 인증서로 사인한다.
③ 인증서 배포
SSL 인증서와 코드사인 인증서는 클라이언트로부터의 SSL 통신 요청이 있거나 또는 사인된 코드의
요청이 있는 경우 클라이언트로 내려가게 된다.
SSL 통신 및 3rd
파티 코드를 사용하기 위해서는 통신하려고 하는 서버를 신뢰할 수 있는지 또는
실행하려는 코드를 신뢰할 수 있는지를 확인하는 작업이 필요하다. 클라이언트에서는 인증서를
통해서 서버 및 게시자를 신뢰할 수 있는지 확인하게 된다.
④ 인증서 유효 여부 조회
클라이언트에서는 인증서를 통해서 배포된 “공개키”, “게시자 정보” 등이 유효한지 즉 외부로부터의
변경이 없었고, 만료 기간이 아직 유효한지 등등의 조회를 인증기관에 보낼 수 있다. 문제는 인증서
자체도 무결성 확인을 위해서 해시값을 가지고 있는데 이 해시값을 만들어내기 위해서 사용된

8. 알고리즘으로 SHA-1 이 사용되면 문제가 될 수 있다는 것이다. 아래 링크를 보면 인증서에는
여러가지 정보가 포함되어 있는데, 이런 값들이 수정이 될 수 있다는 것이다. 외부로부터의 원치
않는 수정이 있어도 인식을 하지 못한다면 인증서 기반의 보안 체계에 문제가 생기게 되는 것이다.
SSL 과 인증서에 대해서 좀 더 알아보고 싶다면 아래 링크를 참조한다.
https://wiki.kldp.org/HOWTO/html/SSL-Certificates-HOWTO/x70.html
6. 부록 2. SSL 통신 보안
6.1 SSL 통신 개요
SSL 보안 통신을 위해서는 클라이언트와 서버 사이에 handshaking 을 통해서 다음과 구성 요소가
결정되어야 한다.
■ 통신 프로토콜 결정
■ 공개 키 교환 알고리즘 결정
■ 데이터 암호화 알고리즘 결정
■ 메시지 인증 알고리즘 결정
SSL 통신에서도 “메시지의 무결성( 메시지 인증 알고리즘)”을 체크하기 위한 해시 알고리즘이
사용되고 있다. 클라이언트와 서버의 handshaking 을 통해서 사용 가능한 프로토콜과 알고리즘이
결정되기 때문에 클라이언트 환경과 서버 환경에서의 “SHA2” 지원 여부도 확인해야 한다. 프로토콜,
알고리즘을 좀 더 자세히 설명한다.
보안 통신 구성요소 설명 예
통신 프로토콜 클라이언트, 서버간의 보안 통신을 위한 협상 등의
절차를 정의한다.
SSL2.0/3.0,
TLS1.0/1.1/1.2
공개 키 교환 알고리
즘
“데이터 암호화”에 사용되는 “대칭 키”를 클라이언트
와 서버가 안전하게 공유하기 위한 목적으로 사용된
다. 이 알고리즘은 비대칭 알고리즘( 공개키 알고리
즘)으로서 성능의 관점에서는 크기가 작은 데이터의
암복호화에 사용된다.
RSA
데이터 암복호화 알고
리즘
실제 데이터 암복화에는 “대칭 키”를 사용한다. 대칭
키를 사용하는 암복호화 알고리즘은 성능 관점에서
대량의 데이터를 암복호화하는데 적합하다.
AES,DES/3DES
메시지 인증 알고리즘 클라이언트에서 보내온 메시지의 인증을 위해서 서
버에서 사용된다.
MD5, SHA 패밀리
SSL 인증서에는 메시
지 인증에 사용할 알

9. 고리즘을
공개키 SSL 인증서에는 데이터를 안전하게 교환하기 위한
“공개키”가 포함되어 있다. 공개키는 클라이언트에
배포되어서 “데이터 교환”을 할 때 RSA 같은 비대칭
알고리즘에서 “암호화 키”로 사용된다. 특정 서버에
서 배포한 공개키로 암호화한 데이터는 해당 서버의
“개인키”로만 복호화가 된다. 이 개인키는 서버측의
안전한 곳에 보관된다.
SSL 인증서
6.2 보안 통신 요소 결정
참고로, SSL 통신의 handshaking 동안 여려 종류의 알고리즘을 결정하기 위해서는 건별로 결정하는
것이 아니라 아래에서 말하는 cipher suite 라고 해서 프로토콜 및 알고리즘을 “세트(set)”로
정의해놓고 어떤 세트를 사용할지에 대해서 협상한다.
TLS Handshake Protocol
https://msdn.microsoft.com/ko-kr/library/windows/desktop/aa380513(v=vs.85).aspx
* TLS(Transport Layer Security)
- 최근 Microsoft 사이트에서는 “SSL”용어를 모두 “TL”S 로 변경했다고 한다.
Windows 7 같은 OS 에는 보안 통신을 하기 위해서 다음과 같은 cipher suite 가 정의되어 있다.
알고리즘을 세트로 묶어서 사전에 정의해 둔다. 예를 들어, cipher suite 에는
"TLS_RSA_WITH_AES_128_CBC_SHA256"같은 세트가 있다.
Cipher suite FIPS mode enabled Protocols Exchange Encryption Hash
TLS_RSA_WITH_AES_128_CBC_SHA256 Yes TLS 1.2 RSA AES SHA256
… … … … … …
위 cipher suite 는 비대칭 암호화에 사용되는 키(공개키)를 교환하는 방법(RSA), 데이터의 암호화
방법( AES_128_CBC) 그리고 암호화된 데이터의 무결성을 체크하는 방법( SHA256) 그리고 사용되는
통신 프로토콜( TLS1.2)을 정의하고 있다. 이렇게 set 으로 정의된 Cipher suite 목록을 서버에 보내면,
서버는 이 목록에서 어떤 알고리즘을 사용할지 선택해서 클라이언트에 서버의 결정을 알려준다.
Transport Layer Security
https://en.wikipedia.org/wiki/Transport_Layer_Security

10. 아래 링크를 보면 Microsoft 제품에서 사용되는 다양한 Cipher Suites 가 보여진다.
https://msdn.microsoft.com/ko-kr/library/windows/desktop/aa374757(v=vs.85).aspx
어플리케이션(브라우저 프로그램)에서는 사용될 SSL/TLS 버전에 대해서는 모른다. 다만 보안 통신을
하겠다는 표시만 한다(HTTPS ). 실제로 사용될 보안 통신 프로토콜은 설정을 통해서 정의된다(인터넷
옵션).
6.3 Windows 7, Cipher suite 활성화
Windows 에는 미리 정의된 cipher suite 가 준비되어 있다. 미리 정의된 Cipher suite 는 그룹 정책
관리자를 통해서 확인할 수 있다.
gpedit.msc > 로컬 컴퓨터 정책 > 컴퓨터 구성 > 관리 템플릿 > 네트워크 > SSL 구성 설정 > SSL
암호 그룹 순서
이 프로그램을 이용해서 cipher suite 의 우선 순위도 변경할 수 있다.
이제 서버와 실제로 SSL 통신을 시작하면, 클라이언트와 서버는 handshaking 을 통해서 사용할 SSL
버전, Cipher suite 를 상호 결정해서 사용하게 된다.