SSL/TLS #2, 인증서 검증과 Chain

인증서

• 인증서란, 서버가 암호화/복호화를 위해 사용하는 서버의 공개키 확보와 이 서버의 신원을 증명해주는 존재

인증서 생성과정

• 서버의 소유자가 CSR(Certificate Server Request)를 통해 CA(Certificate Authority)에게 인증서 생성를 요구할 경우, 요청자는 회사의 신원을 확인할 수 있는 내용과 서버의 ‘공개키’를 CA에게 전달
• CA는 서버의 소유자가 보낸 자료를 토대로 인증서(인증서 내부에는 서버의 공개키가 존재)를 생성하고 CA의 개인키로 암호화
• 또한 인증서 주요 정보와 공개키를 HASH 알고리즘을 이용하여 해시값을 생성한 후 개인키로 암호화(전자서명)
• 아래의 서명 알고리즘을 보면 인증서를 개인키로 암호화(RSA)하되 전자서명은 SHA256을 사용했다는 것을 설명

인증서를 사용하여 사용자가 서버를 인증하는 과정

• 사용자가 서버에 접속하고자 게시된 인증서를 요청함
• 서버는 이 인증서를 전달해주고 사용자는 CA에게 이 인증서가 진짜인지 검증을 요청함
• CA는 CA의 공개키를 전달하고, 사용자는 CA의 공개키를 이용하여 인증서를 복호화하여 서버의 공개키와 서버의 신원에 대한 정보를 얻음
• 사용자는 서버에 대한 인증을 거치고 키교환 알고리즘을 시작

인증서를 CA의 개인키로 암호화하는 이유

• 공개키 기반 구조(PKI)에서 공개키와 개인키는 각각 암호화, 복호화(혹은 복호화, 암호화) 역할을 함
• 개인키는 오직 CA만이 가지는 키이므로 CA의 개인키로 암호화하였을 경우, 오직 CA만이 갖는 공개키로만 복호화 가능
• 이 인증서를 CA가 서명했다는 증거로 활용 가능
• 왜 공개키로 암호화하면 안되는가? – > 공개키로 암호화하게 되면 개인키로만 복호화가 가능한데 이 개인키는 CA만이 갖기 때문에 CA만이 복호화가 가능하며, 다른 사용자가 복호화할 수 없음

전자서명이 들어가는 이유

• 위에 언급한 것처럼 인증서는 개인키로 암호화하고 공개키로 복호화하기 때문에 누구나 열어볼 수 있음
• 해커가 중간에 인증서를 가로채서 내용을 위조 / 변조한 다음 다시 사용자에게 보내어도 내용이 변했는지 알 길이 없음
• 따라서 MAC 알고리즘(SHA, MD5 등)으로 해시값을 생성한 후 CA 개인키로 암호화하여 인증서 내부에 첨부함
• 사용자는 인증서를 전달받아 개인키로 암호화된 MD(Message Digest)를 복호화한 다음,  역시 공개키로 복호화된 인증서 내부 데이터를 또다시 전자서명에 사용하였던 알고리즘을 이용하여 해시값 생성
• 이 두 가지를 대조하여 인증서 내부 데이터가 위조 / 변조되었는지 확인 가능
• 개인키로 해시값을 암호화하는 이유 – > 공격자가 메시지를 변경하고자 할 경우, 그 메시지를 토대로 해시값을 만들어 CA의 ‘개인키’로 암호화해야함

인증서 Chain

• 위의 설명에서는 CA의 인증을 통해 인증서의 신뢰성을 얻는다는 것을 추상적으로 표현
• 실제로는 DNS와 같은 구조를 갖고 있음
• 서버에 게시된 각 인증서들은 중간 단계 인증기관이 서명한 것이며, 중간 단계 인증서는 최상위 인증기관(Root)이 서명한 것
• 인증기관이 Chain처럼 연결지어 인증한다고 하여 Chain이라고 함
• 이 인증서가 최상위 기관까지 연결되어있는지 매번 확인하는 것보다는 Chain을 등록하여 증명하는 것이 나음