회원K 2014-10

alpha ssl을 사셔야 해요. comodo는 per server 입니다.
alpha ssl은 대면검증이 아니라서, 2cpu처럼 가끔 이상한 워닝이 나오는게 문제지만.

다람쥐v 2014-10

댓글로 몇 자 적은 것보다는 제대로 설명된 글을 읽어보시는 것이 도움이 되겠지만 간단하게 설명하면 이렇습니다.

상대방과 통신할 때의 보안상 목적이 크게 두 가지가 있습니다. 하나는 메세지의 암호화이고, 하나는 인증입니다.

말그대로 암호화는 통신하는 내용이 제3 자가 보더라도 알 수 없게 하는 것이고, 인증은 내가 지금 통신하는 상대가 사실 제3 자가 위장한 것은 아닌지 확인하는 것입니다.

메세지의 암호화부터 살펴봅시다.

가장 익숙한 암호는 바로 대칭키 암호입니다. 암호화에 쓰이는 키와 복호화에 쓰이는 키가 같습니다. 더 설명이 필요 없을 정도로 간단한 개념인데, 이 방식에 속하는 알고리즘이 AES나 RC4, (3)DES 같은 애들입니다. 나와 상대방이 같은 키를 들고서 서로 통신하면 되는 것입니다.

그런데 대칭키 암호로 상대방과 안전하게 통신하려면 사전에 서로 만나서 키를 맞춰야 합니다. 이것을 키 교환이라고 합니다. 그런데 물리적으로 직접 만나지 않는 이상 키 자체를 암호화해서 보내려고 해도 그 키를 암호화할 또 다른 키가 필요합니다. 따라서 키 교환의 문제가 생깁니다.

이 문제를 해결하기 위해 키 교환 알고리즘이 필요합니다. 키 교환 알고리즘에는 여러가지가 있는데 그중 잘 알려진 것이 RSA 같은 공개키 암호입니다. 이 공개키 암호는 조금 생소할 수 있는데 개념만 간단하게 얘기하면, 대칭키 암호에선 필요한 키가 하나지만 공개키 암호에서는 각각 공개키와 개인(비밀)키라 불리는 한 쌍의 키가 존재합니다. 말 그대로 공개키는 나 이외에 타인이 알아야 하는 키이고, 개인키는 나만 알아야만 하는 키입니다. 이 두 키는 서로 수학적으로 짝이 맺어진 키라서 따로 존재하는 것은 의미가 없고 각각 다른 쌍에서 온 공개키와 개인키는 아무런 연관이 없습니다.

이 공개키와 개인키가 하는 역할은 생각보다 간단합니다. 메세지를 공개키로 암호화하면 그 쌍의 개인키로만 복호화가 가능합니다. 마찬가지로 개인키로 암호화하면 공개키로만 복호화가 됩니다. 반대로 공개키로 암호화한 암호문은 공개키로 풀리지 않고 개인키로 암호화한 암호문은 개인키로 풀리지 않습니다. 이 방식에 속하는 알고리즘이 많이 들어본 RSA나 ElGamal 같은 애들입니다.

키 교환이 필요한 대칭키 암호화 달리 이론적으로는 상대방의 공개키만 알고 있으면 상대방에게 보내고자 하는 메세지를 상대방의 공개키로 암호화해서 보내주면 키 교환 없이도 안전하게 메세지 전달을 할 수 있습니다. 어차피 공개키는 타인이 알아도 상관 없는 키고, 그 공개키로 암호화한 암호문은 그 쌍의 개인키로만 풀리니 암호문은 안전하게 상대방만 복호화해서 메세지를 열어볼 수 있는 것입니다.

그럼 대칭키 암호가 필요 없을 것 같지만 실제로는 어렵습니다. 방금 위에서 이론적으로는 공개키 암호로 메세지를 암호화해서 전달하면 된다고 했던 게 그런 이유인데요, 공개키 암호에 필요한 계산 비용이 대칭키 암호와 비교해서 훨씬 더 높습니다.

그래서 나온 방법이, 대칭키 암호에 필요한 키를 임의로 정하고 이 키를 상대방에게 상대방의 공개키로 암호화해서 전달하는 방법입니다. 대칭키 암호의 키를 서로 정한 후에는 메세지를 대칭키 암호로 암복호화해서 주고 받는 것입니다. 이렇게 하면 키도 안전하게 교환할 수 있고, 성능 문제도 해결할 수 있겠지요.

다 해결된 것 같지만 아직 문제가 있습니다. 쉽게 간과할 수 있는 문제인데요, 예를 들어보겠습니다. 철수와 영희 사이를 시기한 영수가 치졸하게도 철수와 영희 사이에 오간 암호문들을 오랫동안 모두 기록해놨습니다. 그러다가 어느날 영수가 영희의 개인키를 훔쳤는지, 집념 끝에 영희의 개인키를 계산해낸 것인지(!) 몰라도 영희의 개인키를 얻어냈습니다. 이렇게 되면 큰일이 생깁니다. 그동안 철수는 영희의 공개키로 대칭키 암호의 키를 교환했었는데, 영수가 영희의 개인키를 알아버렸고, 그 동안의 암호문을 영수가 들고 있으니 지금까지 철수와 영희가 나눈 대화의 암호문을 모조리 복호화할 수 있게 되어버렸습니다.

제아무리 그때그때 대칭키의 키를 바꿔가면서 메세지를 암호화했어도, 그 키를 암호화해서 전달하는 공개키가 뚫려버리면 아무런 소용이 없게 됩니다. 대칭키의 키를 바꿔가면서 메세지를 암호화한 것은 대칭키 암호의 키 하나가 뚫려도 그 키로 암호화된 암호문만 영향을 받고 다른 암호문은 아직 안전하도록 하기 위한 것인데, 이것을 PFS(perfect forward secrecy)라고 합니다. 하지만 이런식으로는 PFS 구현이 안됩니다. 따라서 키를 암호화해서 전달하는 것이 아니라 키 교환에만 쓸 수 있는 알고리즘을 따로 쓰기로 합니다.

이런 키 교환 알고리즘에는 Diffie-Hellman 같은 것이 있습니다. 구현은 어려워도 개념은 어렵지 않은데, 나와 상대방이 각각 자신의 비밀키를 정해둡니다. 그런 다음 나와 상대방이 같이 쓸 공통키 하나를 정합니다. 그러고 나서 각자 자신의 비밀키와 아까 정한 공통키 두 키를 수학적인 방법으로 서로 분리할 수 없도록 섞어서 중간키를 만든 다음 상대방에게 보냅니다. 또 각자 상대방으로부터 받은 중간키에 자신의 비밀키를 섞습니다. 이렇게 되면 나는 내 비밀키와 공통키에 상대방의 비밀키, 세 개가 섞인 키를 갖게 되고, 상대방도 마찬가지로 상대방 자신의 비밀키와 공통키 그리고 내 비밀키 세 개가 섞인 똑같은 키를 갖게 됩니다. 이 키를 대칭키 암호의 키로 씁니다.

분리할 수 없도록 섞는다는 개념은 물감을 섞는 것에 비유하면 쉽습니다. 키를 물감에 대응시키면 되는데, 두 물감을 섞어서 하나의 색을 만들긴 쉬워도 원래 두 물감으로 분리해내는 것은 사실상 불가능에 가깝습니다. 따라서 중간에서 키 교환하는 내용을 감시하고 있어도 중간키에서 공통키와 비밀키를 분리해낼 수 없기 때문에 최종키를 알아낼 수 없습니다.

이 Diffie-Hellman에 쓰이는 비밀키를 고정해놓고 써도 되지만 이 비밀키가 탄로나면 역시 똑같은 문제가 생깁니다. 그래서 이 비밀키를 그때그때 바꿔가면서 키를 교환하면, 암호문 하나가 뚫려도 다른 암호문과 아무런 관계가 없으므로 다른 암호문에는 아무런 영향을 주지 못합니다. 이것을 ephemeral diffie-hellman이라고 합니다. 하루살이 키교환인 것이지요.

이렇게 해서 메세지의 암호화는 해결이 됐습니다. 그 다음 필요한 게 인증인데 이 인증은 역시 공개키 암호로 어렵지 않게 구현이 가능합니다. 우선 전제가 필요한데, 상대방의 공개키를 내가 알고 있어야 한다는 점입니다. 상대방이 철수임을 알고 싶으면 사전에 철수의 공개키를 내가 갖고 있어야 하고, 영희임을 알고 싶으면 영희의 공개키를 알고 있어야 합니다. 어, 근데 공개키는 공개된 키니까 아무나 알 수 있어서 문제되지 않을까? 싶지만 그렇지 않습니다.

방법은 이렇습니다. 상대방이 철수임을 확인하고 싶으면 임의의 메세지를 철수의 공개키로 암호화해서 상대방에게 보냅니다. 만약 상대방이 철수라면 철수 자신의 개인키를 갖고 있으므로, 자신의 공개키로 암호화된 암호문을 풀 수 있을 것이고, 내가 보낸 메세지의 원문을 나에게 돌려줄 것입니다. 이때 상대방이 철수임을 알 수 있겠지요. 만약 철수가 아니라면 철수의 공개키만 알고 있고 개인키는 모르기 때문에 암호문을 풀 수 없을 것입니다.

하지만 이런 방식으로는 1000명을 인증하려면 1000명 모두의 공개키를 알고 있어야 합니다. 이것은 문제가 됩니다. 어느날 갑자기 철수가 어떤 이유로 공개키를 바꿨을 수도 있고, 또 영희가 철수인척 하면서 영희 자신의 공개키를 나에게 알려주는데 이게 진짜 철수인지 아닌지 확인할 길이 없습니다.

그래서 나온 방법 중 하나가 PKI(public key infrastructure)라는 것입니다. 모두가 신뢰하는 인증기관을 하나 두고 각각의 사용자는 그 인증기관에 가서 신원확인을 받은 후 신분증 역할을 하는 인증서를 발급받는 것입니다. 우리가 전자상거래에서 쓰는 공인인증서도 이런 인증서입니다. 인증서에는 나의 공개키와 나에 대한 개체 식별 정보가 들어있고, 그 내용에 대한 인증기관의 서명도 들어있습니다.

이때엔 내가 확인하고자 하는 상대방의 공개키를 모두 알 필요가 없습니다. 철수가 자신의 인증서를 나에게 보내면 나는 인증서에 있는 식별 정보를 보고서 상대방 자신이 철수라고 주장하는 것을 확인할 수 있고, 인증기관의 서명을 보고 철수가 맞음을 인증기관이 확인했단 사실을 알 수 있습니다. 이 인증서에는 공개키가 같이 있으므로 이 공개키로 철수를 인증하면 됩니다.

그런데 서명은 또 어떻게 하는 것일까요. 역시 공개키로 가능합니다. 어떤 메세지에 대해 서명을 하고 싶으면, 내 개인키로 그 메세지를 암호화해서 그 메세지와 암호문을 같이 보내주는 것입니다. 상대방은 그 암호문을 내 공개키로 복호화를 해보고 그 복호문과 메세지를 비교해서 일치하면 내가 서명한 사실임을 알 수 있는 것이지요. 왜냐면 내 개인키로 암호화한 암호문은 내 공개키로만 풀 수 있으니 가능한 일입니다.

하지만 메세지 내용이 길면 어떡할까요? 공개키 암호는 속도가 느리다고 했는데 말입니다. 그래서 있는 것이 해싱입니다. 해싱은 메세지의 내용을 계산해서 고정된 길이의 코드로 바꿔버리는 함수입니다. 이 함수를 이용하면 메세지를 코드로만 바꿀 수 있고 코드에서 메세지로 바꾸는 것은 거의 불가능합니다. 예를 들어서 각 자리수의 수를 모두 더해버리는 해시함수가 있다고 하면 25125라는 메세지는 2+5+1+2+5 = 15, 1+5=6, 6이라는 코드가 나오는데 이 6을 갖고 다시 25125라는 메세지로 되돌릴 수는 없는 것이지요. 하지만 충돌 역시 없어야 합니다. 25125 말고도 123이라는 메세지도 6이라는 코드가 나옵니다. 이걸 충돌이라고 하는데 잘 만들어진 해시함수는 충돌을 일으키기가 대단히 어렵고 메세지 내용이 1비트만 바뀌어도 코드가 완전히 바뀌어버리는 특성이 있습니다.

이 해시함수를 이용해서 메세지를 짧은 길이의 해시코드로 바꾸고 여기에 서명을 하면 되는 것입니다. 상대방은 내 메세지와 서명을 받고서, 메세지를 같은 해시 함수로 해시코드를 만들어내고 서명을 내 공개키로 복호화하면 같은 해시코드가 나올 것입니다. 이렇게 서명을 검증할 수 있습니다.

물론 위에서 언급한 내용 말고도 많은 알고리즘과 많은 조건이 있지만 그나마 간략하게 한 것이 이 정도입니다. 이렇게 생각할 것이 많은 암호통신을 간단하게 해주는 것이 SSL/TLS 같은 것입니다. SSL는 메세지 암호, 상호 개체 인증, 메세지 인증 등, 여러 보안요소에 대한 요구사항에 대해 요구사항이 바뀌어도 수정 없이 유연하게 보안을 제공해줄 수 있는 통신 계층입니다.

SSL을 이용하면 보안 연결에 여러가지 알고리즘을 적용할 수 있는데 이것을 cipher suite라고 합니다. 크롬 같은 브라우저로 https://www.google.com에 접속해보면 그 cipher-suite를 확인할 수 있는데 google의 경우에는 메세지 암호화에는 128비트 키의 AES-GCM 방식으로 메세지 암호화와 메세지 인증을 동시에 하고, ECDHE로 키교환을 하며 2048비트 키의 RSA 방식로 개체 인증을 수행하는 것으로 나옵니다. 또 https://nid.naver.com의 경우에는 128비트 키의 RC4 방식으로 메세지를 암호화하고 SHA1 해시함수로 메세지 인증을 수행하고, 2048비트 키의 RSA로 키 교환 및 인증을 하는 것으로 나옵니다.

이야기로 풀어나가다보니 간단하게 설명한다고 한 것이 많이 길어졌습니다만 이해하시기에는 도움이 되실 것이라 생각됩니다.

SEITIES승훈… 2014-10

감사드립니다.

언제 기회가 된다면 자세하게 좀더 이야기 듣고 싶어지네요~ 제가 좀더 공부를 해서 질문을 할 수 있는 레벨이 된후에 대화를 해야 말이 통하겠죠~