이 포스트는 널널한 개발자님 강의를 참조하여 작성하였습니다.
공개키 신뢰를 위한 검증체계
앞서 설명했듯이 MITM 공격상황이 되면 수신한 key도 신뢰할 수 없다라는 것이다. 그래서 대책이 뭐냐면 내용증명이라는 것을 예시로 들 수 있다. 내용증명이라는게 뭐냐면 어떤 사람이 누군가한테 문서를 보낼 때 어떻게 조치를 할 것이라고 문서를 보낸다. 이 문서를 내가 보내는 것이 아닌 3개정도를 만들어서 하나는 내가 갖고 나머지를 우체국이 가져서 나머지 하나를 상대편에게 보내는 형태이다. 그러면 내용증면은 문서의 내용이 어떻고 이런것을 우체국의 증빙으로 남게 된다. 어쨌든 중요한게 우체국이라는 것이 등장한다는 것이다. 즉, 국민이라는 개인들이 자기들간에 대화를 한 것을 공적으로 증명받을려고 내용증명을 하는건데 이 증명을 위해 공공기관이 개입을 하는 것이다. 그래서 여기서 우체국이 증명을 대행해주는 것이다. 그러면 이 예시를 MITM 공격상황에 넣어서 생각해보자.
PKI 인증체계
- PAA(Policy Approval Authorities, 과학기술정보통신부) : 공인 인증서에 대한 정책을 결정하고 하위 기관의 정책을 승인하는 기 관이다. 우리나라는 미래창조과학부가 담당한다.
- PCA(Policy Certification Authorities, 정책인증기관) : RootCA를 발급하고 기본 정책을 수립하는 기관으로, 우리나라의 KISA(Korea Information Security Agency, 한국정보보호진흥 원)가 여기에 해당한다. RootCA는 모든 인증서의 기초가 되는 인 증서를 보유하고 있으며, 인증서에 포함된 공개키에 대응되는 개 인키로 생성한 자체 서명 인증서를 사용한다.
- CA(Certification Authority, 인증기관) : PCA의 하 위 기관으로 인증서 발급과 취소 등의 실질적인 업무 를 하는 기관이다. yessign(금융결제원), NCA(한국 전산원) 등이 이에 속하며, 상호 간 신뢰한다.
- RA(Registration Authority, 등록기관) : 사용자의 신분을 확인하고 CA 간 인터페이스를 제공하는 기관 이다.
- CA의 Private key로 Hash결과가 암호화 되어 있으며 검증 과정에서는 PC에 사전 배포된 CA Public key(기관 인증서 에 포함)로 암호를 풀어 검증할 수 있다.
서버에서 호스트로 public key가 올 때 이 key를 검증을 해야하는데 그 전에 1가지를 생각해보자. 서버에서 key쌍을 생성할 때 많은 비용이 발생한다. 즉, 많은 전산자원을 소모하게 된다. 그러면 이 key쌍을 매번 생성할 것인가의 문제가 있다. 무슨 뜻이냐면 다음 예시를 통해 말할 수 있을 것이다. 우리가 무엇을 먹을때 일회용 나무젓가락을 쓸 것이다. 이 나무 젓가락을 이용해 음식을 먹고 버릴 것이다. 그런데 만약에 쇠로 된 젓가락을 한번만 이용하고 버리는 것은 말이 안 될것이다. 그래서 실제로 key쌍ㄷ으로 만들어지는 유효기간 즉, key의 강성이 10년이상 젓가락으로 치면 쇠젓가락을 일회용으로 쓰는 것과 같은 효과이다. 그래서 이 key쌍을 예전에는 매번 생성하는 전략을 취했다면 오늘날은 유효기간을 6개월로 정하고 6개월마다 한번 생성하는 전략을 취하는걸로 바뀌었다.
만약 웹서버가 있다고 하고 이 서버에 실무자가 key전략을 바꿀려고 한다고 한다. 즉, 매번 생성하는 전략을 6개월마다 1회생성 전략으로 바꾸는 것이다. 또한 MITM공격에 대비해 클라이언트와 상호인증체계를 도입하려고 한다고 보자. 그러면 실무자는 RA에 가거나 이메일로 보내서 public key와 private key 한쌍을 구매한다고 구매요청을 보낸다. 그러면 RA는 CA에게 구매요청이 들어왔다고 전달을 하고 CA는 key쌍을 생성을 한다. 이때 key쌍을 생성을 할때 특이한게 어느 문서에 user information을 작성하고 다음으로 public key를 집어넣는다. 그리고 user information과 public key를 hash연산을 진행하고 이 hash결과를 CA의 private key로 디지털 서명(암호화)를 한다. 그리고 이 값을 이전에 user information과 public key에 담아 둔곳에 무결성 검사를 위해 넣어두고 이 것을 X.509형식으로 맞춘다. 그리고 이것을 인증서라고 부른다. 즉, 인증서와 private key를 RA에게 전달하고 RA는 실무자에게 전달을 한다. 그러면 실무자는 이것을 웹서버에 설치를 한다. 그리고 웹서버이니 클라이언트와 HTTP통신을 할텐데 이 때 웹서버에 설치된 인증서를 SSL인증서라고 한다. 즉, 이전에는 일반 public key였다면 지금은 SSL인증서로 변경이 된 것이다.
💡 참고
SSL인증서의 유효기간은 보통 6개월 혹은 1년이다.
그러면 이제 호스트가 웹서버와 HTTPS통신을 하겠다고 접속을 한다. 그러면 그 웹서버에서 public key가 아닌 SSL인증서가 날라온다, 그러면 이 인증서를 어떻게 검증을 할까? 이 때 이전의 내용증명처럼 CA가 우체국역할을 해준다. 즉 웹서버와 호스트가 CA를 신뢰한다는 것이다. 그러면 날라온 SSL인증서의 암호화된 hash값을 OS가 보안업데이트로 설치한 기관인증서로 암호화된 hash를 복호화한다. 즉, OS가 보안업데이트로 설치한 기관인증서에는 CA의 public key가 들어있다는 것을 알 수 있다. 그래서 복호화한 hash와 넘어온 인증서의 user information과 public key를 같이 hash해서 나온 결과와 비교해서 일치하면 위변조되지 않은 인증서라고 할 수 있다. 그러면 이 때 public key를 꺼내서 클라이언트의 session key를 암호호해서 서버측에 전달을 한다. 이렇게 해서 통신이 이루어지고 MITM공격을 방지할 수 있다.
SSL 인증서
SSL인증서를 검증하는 방법은 인증서를 발급한 CA의 인증서에 포함된 public key를 이용해 hash결과를 복호화하면 된다.
