PKI 시스템에서 가장 대표적인 기술이라면 아마도 인증서 관련된 내용일거다.
그 중에서도 가장 보편적으로 많이 사용되는거라면, 아마도 SSL/TLS 이지 않을까 싶다.
그런데, SSL 을 비롯한 PKI 문제를 너무 기술적인 접근만 이뤄지고 있는 것 같아서 그 기술적 배경에 대해서
간단히 정리를 하고자한다.
PKI는 Public Key Infrastructure 이다.
여기서 Infrastructure라는 단어가 중요한데, 보안/암호 시스템에서 가장 중요한 단어 하나를 꼽으라면,
주저없이 신뢰라는 단어를 꺼내고 싶다.
이 신뢰라는 단어는 기술적으로 강하게 묶이도록 시스템을 구성하지만, 그렇지 않은 경우도 존재하기 때문이다.
예를 들어서 Self Sign된 인증서로 SSL/TLS 서비스를 구성할 때, 웹브라우저는 해당 인증서를 신뢰하겠느냐고 물어본다.
이때는 기술적인 부분보다 사용자에게 웹사이트의 신뢰여부를 확인 받는것이다.
개발자들에게는 SSL/TLS(공인인증서 또한 마찬가지다) 시스템 구축시에 가장 많이 발생하는 오류가
Certificate chain 오류나 PKIX path building 오류이다.
인증서를 검증하면서 오류가 발생하는 것인데, 대부분 CA인증서를 신뢰하도록 설정하지 않아서 문제가 생기는 것들이다.
즉, 인증서는 그 인증서를 발급한 상위 기관(CA)이 있고, 그 상위기관의 인증서 또한 누군가에 의해서 발급이 된다.
그러다 최상위 기관의 인증서는 스스로 발급을 하고, 전자서명을 하는데 이는 Self Sign으로 처리된다.
이렇듯 각 인증서의 상/하 관계는 Chain으로 구성되어 있다.
하나의 인증서를 검증하기 위해서는 반드시 Certificate Chain도 함께 검증을 해야 그 신뢰관계가 형성되는 것이다.
그렇다면, 시스템에서 어떻게 Certificate Chain을 신뢰하도록 할까?
그건 여러 방법이 있겠지만, 그중에 하나가 Keystore를 만들고, 이를 신뢰하도록 설정하는 것이다.
Certificate Chain의 모든 신뢰관계를 갖는 인증서를 Keystore에 넣어두고, 해당 Keystore를 최종적으로 신뢰하도록 한다면,
최소한 우리가 가장 중요하다가 신뢰하는 인증서들을 안전하게 사용할 수 있다.
이후부터는 순수하게 기술적인 문제만이 존재한다.
또 하나 고려해야 할 사항이 있다면, 신뢰의 정도문제를 얘기할 수 있다.
절대적으로 신뢰할 수 있는 것인지, 현재의 시스템에서 적당히 신뢰할 수 있는것인지, ...
이에 따라서 전체 시스템/서비스의 보안강도 또한 연관되어 결정될 수 있다.
좀 더 좋은 방법, 좀 더 귀찮지만 더 신뢰할 수 있다면 보안측면에서는 좀 더 향상된 시스템임에 분명하다.
(보안적인 측면과 편리성, 가용성, 접근성등은 상반된 입장으로 늘 부딪히기 마련이다.)
대부분의 개발자들이 보안시스템의 개념이나 키관리의 중요한 개념없이 무조건적인 기술개발만 집착을 하다보니
정작 가장 중요한 부분을 놓치는 경우가 왕왕있다.
다시 한번 강조하지만 보안/암호 시스템에서는 가장 중유한 것은 신뢰이며, 이 신뢰관계를 지속적으로 유지하는가가 그 어떤 것보다 중요하다.
많은 경우 신뢰관계를 쫓아가다보면 마지막 단계는 사람과 만나기도 하는데, 이것을 시스템/프로세스화 하도록 하는것이 좋은 시스템의 척도이지 않을까 싶다.
그 중에서도 가장 보편적으로 많이 사용되는거라면, 아마도 SSL/TLS 이지 않을까 싶다.
그런데, SSL 을 비롯한 PKI 문제를 너무 기술적인 접근만 이뤄지고 있는 것 같아서 그 기술적 배경에 대해서
간단히 정리를 하고자한다.
PKI는 Public Key Infrastructure 이다.
여기서 Infrastructure라는 단어가 중요한데, 보안/암호 시스템에서 가장 중요한 단어 하나를 꼽으라면,
주저없이 신뢰라는 단어를 꺼내고 싶다.
이 신뢰라는 단어는 기술적으로 강하게 묶이도록 시스템을 구성하지만, 그렇지 않은 경우도 존재하기 때문이다.
예를 들어서 Self Sign된 인증서로 SSL/TLS 서비스를 구성할 때, 웹브라우저는 해당 인증서를 신뢰하겠느냐고 물어본다.
이때는 기술적인 부분보다 사용자에게 웹사이트의 신뢰여부를 확인 받는것이다.
개발자들에게는 SSL/TLS(공인인증서 또한 마찬가지다) 시스템 구축시에 가장 많이 발생하는 오류가
Certificate chain 오류나 PKIX path building 오류이다.
인증서를 검증하면서 오류가 발생하는 것인데, 대부분 CA인증서를 신뢰하도록 설정하지 않아서 문제가 생기는 것들이다.
즉, 인증서는 그 인증서를 발급한 상위 기관(CA)이 있고, 그 상위기관의 인증서 또한 누군가에 의해서 발급이 된다.
그러다 최상위 기관의 인증서는 스스로 발급을 하고, 전자서명을 하는데 이는 Self Sign으로 처리된다.
이렇듯 각 인증서의 상/하 관계는 Chain으로 구성되어 있다.
하나의 인증서를 검증하기 위해서는 반드시 Certificate Chain도 함께 검증을 해야 그 신뢰관계가 형성되는 것이다.
그렇다면, 시스템에서 어떻게 Certificate Chain을 신뢰하도록 할까?
그건 여러 방법이 있겠지만, 그중에 하나가 Keystore를 만들고, 이를 신뢰하도록 설정하는 것이다.
Certificate Chain의 모든 신뢰관계를 갖는 인증서를 Keystore에 넣어두고, 해당 Keystore를 최종적으로 신뢰하도록 한다면,
최소한 우리가 가장 중요하다가 신뢰하는 인증서들을 안전하게 사용할 수 있다.
이후부터는 순수하게 기술적인 문제만이 존재한다.
또 하나 고려해야 할 사항이 있다면, 신뢰의 정도문제를 얘기할 수 있다.
절대적으로 신뢰할 수 있는 것인지, 현재의 시스템에서 적당히 신뢰할 수 있는것인지, ...
이에 따라서 전체 시스템/서비스의 보안강도 또한 연관되어 결정될 수 있다.
좀 더 좋은 방법, 좀 더 귀찮지만 더 신뢰할 수 있다면 보안측면에서는 좀 더 향상된 시스템임에 분명하다.
(보안적인 측면과 편리성, 가용성, 접근성등은 상반된 입장으로 늘 부딪히기 마련이다.)
대부분의 개발자들이 보안시스템의 개념이나 키관리의 중요한 개념없이 무조건적인 기술개발만 집착을 하다보니
정작 가장 중요한 부분을 놓치는 경우가 왕왕있다.
다시 한번 강조하지만 보안/암호 시스템에서는 가장 중유한 것은 신뢰이며, 이 신뢰관계를 지속적으로 유지하는가가 그 어떤 것보다 중요하다.
많은 경우 신뢰관계를 쫓아가다보면 마지막 단계는 사람과 만나기도 하는데, 이것을 시스템/프로세스화 하도록 하는것이 좋은 시스템의 척도이지 않을까 싶다.
