CA Root 인증서, CA 루트 인증서 설치 하나로 특정 사이트나 프로그램, 게임이 되는 이유

CA Root 인증서는 정보 보안 통신에서 대상 서명된 인증서를 검증하는 용도로 사용될 수 있는 신뢰 인증에서 중요한 역할을 수행하는 인증 도구이다.

최근 네트워크 통신으로 비밀번호, 거래, 금전 거래를 진행함에 따라 정보 보호의 중요성이 대두되고 있다. CA 인증서가 무엇인지 이해하기 위해서는 이 정보 보호 원리에 대해서 깊숙하게 이해할 필요가 있다. 이 게시글에서는 상세한 통신 과정을 언급하지는 않고, 간단한 원리에 대해서만 설명한다.

환경 정의

기본적으로 인터넷은 공개된 공간이다. 사용자가 전송하는 모든 내용은 다른 사용자들도 무조건 열람할 수 있으며, 조작될 수도 있고, 변질될 수도 있는 그런 위험한 공간이다. 현실로 비유하자면 확성기에 말을 하는 것과 같다. 누구나 들을 수 있고, 귓속말은 할 수 없다고 가정한다. 이럴 때 다른 사람들은 알아들을 수 없고, 원하는 대상과만 얘기를 하려면 어떻게 해야할까?

암호 통신의 기본 "대칭키"

기본적으로 A, B 간 대화하는 내용을 안전하게 보호하기 위해서는 A, B 당사자만 알고 있는 암호를 활용해서 대화 내용을 암호화하면 된다. 예를 들어 A, B는 친한 친구고 미리 사전에 귓속말을 할 수 있는 공간에서 만나서 {1234} 라는 비밀번호로 대화 내용을 보호하기로 약속한다.

이렇게 사전에 둘만 대화할 수 있는 공간에서 {1234}로 약속하고 공개된 공간에서는 모든 말을 {1234} 라는 비밀번호로 암호화 하면 이 비밀번호를 모르는 사용자들은 이 메시지를 해독할 수 없게 된다.

서로 비밀번호를 알고 있기 때문에 상대가 하는 말을 비밀번호로 해독하면 된다.

그런데 위 방법은 사전에 당사자간 비밀번호를 교환하고 있어야 한다는 문제가 존재한다. 즉 생판 처음 보는 사람들간 귓속말을 할 수 없는 상황이라면 비밀번호를 안전하게 전달할 방법이 없는 것 이다. 공개 공간에서 생판 처음보는 사람한테 확성기로 비밀번호를 전달했다간 다른 사람들도 비밀번호를 알게 된다.

즉 당사자간 비밀번호로 안전하게 통신을 하기 위해서는 비밀번호를 다시 안전하게 교환할 필요성이 있다. 비밀번호를 또 다른 비밀번호로 암호화 통신한다고 하더라도, 또 다른 비밀번호는 다시 노출될 우려가 존재하기 때문에 이런 암호 방식은 비밀번호를 교환하는 데 사용할 수 없다. 여기서 등장한 것이 비대칭 암호화이다.

비대칭 암호화

비대칭 암호화는 일반 대칭키 암호화와는 결이 다르다. 기본 대칭키 암호화는 같은 비밀번호로 암호화하고 해독하는 열쇠 같은 개념이었다면, 비대칭 암호화는 암호화하는 키와 복호화하는 키가 서로 다르다.

대칭키 암호화

비대칭키

기본적으로 비대칭키는 암호 한개가 아니라, 개인키 공개키가 쌍으로 존재한다. 즉 하나를 암호화하고 복호화하는데 개인키와 공개키가 쌍으로 필요하다. 공개키로 암호화한 내용은 절대 공개키로 다시 복호화할 수 없고 해당 쌍의 개인키로만 복호화할 수 있다.

위 상황에서 한 쌍의 공개키, 개인키가 존재할 때, 공개키로 {안녕}을 암호화하고 나온 결과 값을 다시 공개키로는 복호화할 수 없다.

공개키로 암호화된 것은 해당 쌍의 개인키로만 복호화할 수 있다.

한편, 이번에는 반대로 해보자. 개인키를 활용해서 어떤 글을 암호화(서명)하고, 공개키로 복호화(검증)할 수 있다.

개인키로 안녕을 암호화(서명)하더라도, 개인키로 다시 복호화할 수는 없다. 한편 공개키로 이를 복호화(검증)할 수 있다.

위 이미지를 보면, 공개키로 암호화 하고 개인키로 복호화하며

개인키로 암호화(서명)하고 공개키로 복호화(검증)한다. 다만 개인키로 암호화한 경우는 암호화라고 안하고, 서명/검증이라고 하는데 그 이유는 조금 이따가 후술한다.

우선 위 방법을 공개 공간에 그대로 가져와보자.

비대칭키 쌍 생성 및 공개키 노출

먼저 A는 개인키와 공개키를 쌍으로 생성한다. 이 개인키와 공개키는 수학적인 원리로 (소인수 분해) 이 쌍에서만 적용되며 다른 쌍이랑 섞을 수는 없다. A는 자기 자신의 개인키와 공개키를 모두가지고 있다.

이 상태에서 A는 공중에게 공개키를 공유한다. 모든 사람들은 A의 공개키를 알게된다. B도 마찬가지로 A의 공개키를 알게된다.

상대는 공개된 공개키로 대칭키 암호화

잠시 비대칭 암호화 라는 파트를 내비두고, 대칭키 암호화를 생각해보자. 현재 하고 싶은 것은 A와 B가 서로 암호키 {1234}를 교환하는 것이다. 그 과정에서 다른 사람들에게 비밀번호가 노출되지 않는 것이다.

B는 임의의 대칭 암호화를 위한 암호키 {1234}를 생성해서, 알고 있는 A의 공개키로 암호화한다.

이렇게 암호화한 공개키를 공중에게 전달한다. 하지만 공개키로 보호된 대칭키는 A 당사자를 제외하곤 아무도 해독할 수 없다. 왜냐하면 A는 공개키만 공중에 공유했을 뿐, 개인키는 A만 가지고 있기 때문이다. A는 자신이 가지고 있는 개인키로 B가 보내온 메시지를 복호화한다. 그러면 결과적으로 A 와 B는 서로 대칭키 {1234}를 알 수 있게 된다.

A와 B만이 {1234}라는 암호키를 알고 있는 상태에서 더 이상 비대칭 암호화의 필요성은 없어졌다. 이제 이것이 없더라도 서로 알고 있는 암호키{1234}로 열쇠 방식의 암/복호화인 대칭 암호화/복호화를 하면 된다.

보안 문제점 위 방법은 완전해 보이지만 물리적으로 심각한 문제가 하나있다. 변조될 가능성이 있다는 것이다. 메시지가 변조될 가능성이 있다는 것은 가로챌 수 있다는 것이며 이 수법을 통해서 암호화를 무력화시킬 수 있다. 어떤 원리로 무력화되는 것인지, 알아보자.

공개키의 변조

초반으로 돌아가서, A가 공개키를 공중에게 공유하는 부분을 보자. 악의적인 해커가 A가 말하는 것을 가로채고 자기가 임의로 만든 공개키를 전달하는 것이다.

먼저 해커는 A가 말하는 내용을 제거(변조)한다. 이렇게 제거된 사실은 A도 모른다. 비유적인 표현으로 A가 확성기를 통해 말하는 공개키를 방음, 역위상 확성기 등을 통해 묵살하는 방법이 있다. 컴퓨터 네트워크 통신에서는 기본적으로 전달, 전달하는 구조라 전달하는 중간자가 묵살할 수 있다.

해커는 기존 A가 말하는 내용을 묵살(변조)하여 해커가 임의로 생성한 자신의 공개키/개인키 쌍에서 공개키를 전달한다.

B의 입장에서는 받은 정보가 해커의 공개키이며 이 공개키가 A것인지 확인 할 방법이 없다. 당연히 A 가 말한 것이라고 생각하고, 받은 공개키로 대칭키를 암호화하여 보내면, 해커는 해커의 개인키로 복호화하여 대칭키를 알아내게 된다.

해커는 알아낸 대칭키 1234로 다시 자기가 B인척 A에게 이번에는 A의 공개키로 1234를 암호화하여 보낸다.해커는 A의 공개키를 알고 있는 이유가 초반에 A의 공개키 발언을 묵살하면서 A의 공개키를 저장해놨기 때문이다.

해커가 가로채어 알게된 1234를 A에게 공개키로 암호화해서 보내면 A는 당연히 B가 보낸줄 알고 복호화하며, 1234를 받아 결과적으로 3명이 모두 대칭키를 알게 된다.

이는 결과적으로 B가 받은 메시지가 A가 공개한 공개키인지 검증할 수 없어서 발생하는 문제이다. 무작정 받는 공개키가 조작될 수 있기 때문이다. 즉,A가 보내온 공개키인지만 검증할 수 있다면 아무리 해커가 가로채더라도 대화를 안하면 된다. 그러면 유출될 일도 없다. 이러한 문제에서 벗어날 수 있다. 이러한 과정에서 사용되는 것이 서명 및 검증이다.

서명 및 검증

서명 및 검증을 위해서는 검증을 해주는 대리인이 필요하다. 이를 우리는 CA 및 루트 CA 라고 부른다.

CA는 기본적으로 서로 주고 받는 내용의 출처가 맞는지 검증을 해주는 역할을 한다. 그렇다고 해서 모든 메시지가 CA를 거치는 것이 아니라, 이 또한 수학적인 원리로 인증키를 이용해서 검증을 수행한다. 그렇기 때문에 CA는 매우 신뢰할 수 있는 사람들로 한정되어 있어야 한다.

CA 비대칭 쌍 생성

기본적으로 CA도 CA 자기 자신의 공개키, 개인키 쌍을 생성해서 두고 있는다. 다만 공개키는 공중에게 영구적으로 배포한다.

기본적으로 CA 공개키는 영구적으로 공개된다. 즉 인터넷을 통해서 배포되기 보다는, 매우 초반에는 운영체제 자체에 배포, 내장되어 있다. 운영체제 업데이트를 통해서 CA 공개키가 다시 업데이트된다. 이러한 인증서 발급사, 회사는 정해져있다.

서명 받기

먼저 A는 자신의 공개키를 공유하기 전에, 자신의 공개키와 성함을 CA에게 서명을 받는다. CA는 금전적인 비용을 받고 A의 성함과 공개키를 묶어 CA의 개인키로 서명을 해주고 서명본(서명된 공개키)을 돌려준다. 이는 통신하기 전에 발급을 받는 것이 아니라, 서비스를 개발하거나 신청할 때 즉 대상과 계약하기 전에 최초 한 번 발급 받는 것으로 수동으로 CA에게 직접 가서 발급받아야 한다 CA로부터 서명된 인증서를 받았으면, 이제 앞으로 A는 통신할 때 자신의 공개키를 바로 공유하는 것이 아니라, 서명된 인증서(A공개키, 이름 A 서명본)을 공유한다.

B는 서명된 인증서를 받을 것이며, 이미 알고 있는 CA 공개키로 복호화(검증)한다.

B 입장에서는 받은 내용이 CA 에 의해서 서명된 것을 보아, 이름 A의 공개키는 "A공개키"가 맞다는 사실을 확정할 수 있게 된다.

위 상황에서 해커가 가로채서 해커 개인의 공개키로 변조했다고 가정하자.

B는 루트 CA 공개키(인증서)로 검증하면 위조라는 사실을 알 수 있다. 그 이유는 해커는 그 어떠한 방법을 동원하더라도 CA가 서명한 위조본을 수학적으로 조작할 수 없기 때문이다. 해커가 위조하기 위해서는 해당 A라는 이름으로 공인된 CA에게 거짓된 서류를 제출해서 승인받는 방법밖에 없는데 공인된 CA는 절대 이를 승인하여 서명해줄 일이 없다. 그렇기 때문에 이름이 신뢰할 수 있는 인증서라고 하는 것이다.

이렇게 B는 변조라는 사실이 확인되면 연결을 그냥 끊어버린다. 통신할 것도 없다. 안전한지 증명할 수 없기 때문이다. 실제 인터넷을 하다보면, 아래와 같은 오류 메시지가 뜨곤 한다.

A가 보내온 서버의 인증서를 B 입장에서 CA로 검증할 수 없기 때문이다. 검증할 수 없는 이유는 CA 공개키(인증서)가 설치되어 있지 않거나, 시간이 만료됐거나, 성함(아이피, 도메인 주소)가 다르거나 등의 이유로 신뢰할 수 없기에 차단하는 것이다. 이는 인터넷에만 국한되는 것이 아니다. 게임 등 보안 통신이 진행되는 곳에서도 해당 문제가 발생할 수 있다.

인증서 오류

가끔, 각종 다양한 환경에서 다양한 이유로 인증서 오류를 만나보게 된다. 특히 게임이나 소프트웨어 같은 경우 신뢰할 수 있는 인증서가 엉켜버리면 아예 연결 자체가 안되는 등의 문제가 발생할 수 있다. 최근 친구와 게임을 같이 플레이하기 위해 로그인을 하는데, 친구는 로그인이 안된다고 하는 것 이다. 나는 접속이 잘되는데, 친구는 안된다는 것 보면, 서버 측 문제 보다는 루트 CA 인증서 측 문제로 판단하였고, 하나씩 돌아가면서 확인한 결과 Starfield Services Root Certificate Authority 인증서 가 없어서 발생하는 문제였다. 왜 없었는지는 알 수 없었는데, 해당 인증서를 설치하고 게임을 로그인하더니... 잘 되더라... 나는 노트북이 한 대 더 있기 때문에, 인증서를 그대로 복사해서 설치했지만, 다른 사람들에게 이 문제를 공유하기 위해서 공식 제공하는 CA 인증서를 찾을 필요가 있었고, https://www.amazontrust.com/repository/ 에서 해당 Root CA 인증서를 배포하고 있음을 확인할 수 있었다. 해당 페이지에 따르면 Root CA는 Creative Commons Attribution-NoDerivatives 4.0 International License 조건 하에 배포된다고 한다. https://www.amazontrust.com/repository/SFSRootCAG2.cer 을 신뢰할 수 있는 저장소에 내려받고 설치하는 방법을 제보하고 공유했는데...... 생각보다 이 문제 때문에 막혀있던 게이머들이 많았나보다. 오죽하면 악성 게시글이라는 오해도 받았는데, 개발 생활에서 나름 재밌는 해프닝이었다.

인터넷을 보면 타 RPG 게임을 설치하면 해당 게임 로그인 접속 불가능 문제가 해결된다는 부분도 있었는데, 일리 있는 말이다. 위 CA 인증서는 각 개인이 발급하는 것이 아니라, 공인된 회사에서 생성하여 발급, 관리하는 것이기 때문에 같이 CA가 중복되는 경우가 매우 많다. 즉 이 인증서 문제가 발생하면 해당 인증서로 검증 받는 다른 하위 인증서에도 문제가 발생할 수 있는 것이며, 이를 해결하면 다른 문제가 해결될 수도 있는 것이다.

운동 가야하느라 친구랑 빨리 한 판 한다고, 로그인 문제를 가능한 선에서 빠르게 해결한 것인데, 이 정보가 같은 플레이어들에게 도움이 되었다니, 다행이다.