SSL 그리고 대칭과 비대칭 암호화 알고리즘

http 프로토콜과 https 프로토콜의 가장 큰 차이는 통신 과정에서 암호화 알고리즘을 사용하는 SSL(Secure Socket Layer) 인증 절차가 기능하고 있는지이다. SSL 프로토콜은 이를 통해 서버와 클라이언트 간의 안정적인 통신을 보장한다.

 

1. 암호화 알고리즘이란?
2. 비대칭 암호 알고리즘의 원리
3. 비대칭 암호 알고리즘의 한계와 대칭 알고리즘

 

1. 암호화 알고리즘이란?

암호화 알고리즘은 크게 두 가지로 나눌 수 있다.

• 대칭 암호화 알고리즘 - 암호화할 때 쓰는 키와 복호화할 때 쓰는 키 값이 동일하다.
• 비대칭 암호화 알고리즘 - 하나의 알고리즘에 두 개의 키가 있으며 이를 공개 상태에 따라서 Public key로 부르거나 Private Key로 부를 수 있다.

 

비대칭 암호화 알고리즘은 보통 암호화할 때 Public Key나 Private Key 둘 중 아무 키나 사용할 수 있으며 복호화할 땐 단지 다른 키를 사용하면 된다.

 

2. 비대칭 암호 알고리즘의 원리

어떤 알 수 없는 큰 수 16,777,216이 있다고 치자. 그리고 이 큰 수에 그냥 임의로 정한 어떤 수 2,951을 나누어보자.

 

여기서 우린 다음과 같은 고민을 하게 된다.

• 어느 자릿수가 결과의 첫 번째 자릿수가 되는가?  1677 보다 2951이 크니 우린 그 뒷자리부터 첫 번째 수를 넣기 시작할 것이다.
• 첫 번째 자릿수에는 어떤 수가 적절할까? 대충 5부터 시작할까? 아니면 6인가?

 

컴퓨터는 이 나눗셈을 아마 이렇게 할지 모른다.

 

1. 2,951 곱하기 1은 숫자 1보다 크다. 다음 자릿수로 넘어간다.
2. 2,951 곱하기 1은 숫자 16보다 크다. 다음 자릿수로 넘어간다.
3. 2,951 곱하기 1은 숫자 167보다 크다. 다음 자릿수로 넘어간다.
4. 2,951 곱하기 1은 숫자 1677보다 크다. 다음 자릿수로 넘어간다
5. 2,951 곱하기 1은 숫자 16777보다 작다. 이제 2,951 곱하기 2를 해보자.
6. 2,951 곱하기 2는 숫자 16777보다 작다, 이제 2,951 곱하기 3을 해보자.
7. ...

이처럼 나눗셈은 곱셈보다 훨씬 많은 연산을 하게 된다.

이런 나눗셈 연산에 비해 그냥 임의의 수를 이용해 16,777,216을 만드는 일은 쉽다.

예를 들어 그냥 아무렇게나 정한 4자리의 수 두 개를 고른 후 작업을 한다고 생각해보자.

• 어떤 사람 A는 생각 없이 2,951을 골랐고 또 생각 없이 5,685 값을 골랐다.
• 곱해보니 16,776,435 값이 나온다.
• 우변을 16,777,216으로 맞춰달라는 요구가 있다.
• 두 개의 수(16,777,216, 16,776,435)를 빼서 그 차이가 781 임을 확인했다.
• 따라서 2,951 X 5,685 +781 = 16,777,216이라는 공식이 만들어졌다.

 

공식을 만드는데 필요한 연산과 , 나눗셈을 통해 알 수 없는 값 하나를(5,685) 찾아내는 연산 간에 시간 복잡도를 생각해보자.

 

	공식 만드는 작업	모르는 수 찾아내는 나눗셈 작업
4자리 곱하기 1자리 연산	2195 x 5 2195 x 6 2195 x 8 2195 x 5 (총 4번)	자리 찾는데 4번 숫자 5 찾는데 (5번 + 1번) 숫자 6 찾는데 (6번 + 1번) 숫자 8 찾는데 (8번 + 1번) 숫자 5 찾는데 (5번 + 1번) (총 32번)
쉬프트 연산(10의 몇승 곱해주기)	3번	32번 x 3번 정도?
덧셈이나 뺄셈 연산	4번	32번 + 5번 정도?

아무리 적게 잡아도 7~8배 정도 차이는 난다.

만약 이런 차이가 7~8배가 아니라 200억 배, 20조 배 정도 차이가 나는 연산이 있다면 어떨까?

예를 들어 나눗셈의 경우처럼 매 자릿수마다 0부터 9 사이 숫자 중 하나를 선택하고 그것을 검증하면 되는 10지 선다형 찍기가 아니라, 한 40억 선다형 찍기를 해야 한다면? 그리고 나눗셈처럼 선택이 틀리더라도 실패를 통해 한 발자국 한 발자국 정답에 접근하게 되는 것이 아니라 한번 찍어서 틀린 게 전혀 도움이 안 돼서, 아무 근거 없이 또 찍어야 하는 40억 선다형 찍기라면?

 

엄청 운이 좋아서 40억 개의 옵션들 중에 잘 찍으면 정답만 연속으로 쏙쏙 골라서 결론을 도출할 수도 있을 것이다. 단지 그 확률이 매우 낮을 뿐.

사하라 사막에 좁쌀만한 다이아몬드가 어딘가 존재한다고 생각해보자. 그곳에 처음 간 누군가가 무심코 사막의 모래를 한주먹 집었는데 손안에 반짝이는 무언가가 존재할 확률은 분명 있긴 있으니까.

요즘 패스워드를 입력할 때 보통 5번의 기회를 주더라. 만약 사하라 사막에서 다섯 번 모래를 쥐어서 그 안에 다이아몬드를 찾아낼 수 있다면... 그렇게 하는 것을 권장한다...

우리는 이런 상황을, 다이아몬드를 숨겨 두었다고 볼 수 있다.

 

이제 우리에게 2,951과 16,777,216 같은 성질의, 어떤 거대한 수들이 주어졌고 4만 년쯤 걸릴 것으로 예상되는 40억 선다형 나눗셈 연산이 앞에 있다고 가정해보자.

그런데 누군가가 나타나서 5685와 781 같은 수를 툭 던져 주는 것이다.

당장 곱셈과 덧셈을 해보고. "오 당신이 이 공식을 만들었군요!"라고 확신하게 될 것이다.

2951과 16,777,216 같은 숫자 쌍을 세상에 퍼트림으로써 5685와 781의 숫자 쌍을 유일하게 알고 있는 한 사람은 자신의 신분을 증명할 수 있는 것이다.

 

이때 (2951, 16,777,216)의 쌍을 public key라고 부르고 인터넷상에 공개적으로 배포되어있다고 가정해보자.

그리고( 5685, 781)을 private key 부르며 오직 한 서버(CA)만이 이 숫자 쌍을 보유하고 있다고 가정해보겠다.

 

그리고 인증서버(CA)가 만든 어떤 문자열이 있고 그 문자열의 내용은 아래와 같다.

 

"전 여러분이 다들 가지고 계시는 그 퍼블릭 키를 만든 인증 서버입니다. 제가 보장합니다. 이 사이트(www.aabbcc.com)는 정상적인 사이트입니다 사용자 분들은 마음껏 사용하셔도 됩니다"

 

문자열은 문자 코드 값(아스키코드나, 유니코드 값)으로 표현될 수 있다. '여'는 0xad30 '러'는 0xb349, '분'은 0x... 예를 들자면 이런 식으로 말이다.

이걸 연속되는 하나의 큰 수라고 생각하고 이 수의 값을 '문자열 값'이라고 명명하겠다

그러면 아래와 같은 암호화 결과물을 만들고 해석할 수 있다.

 

• 인증 서버는 이 문자열 값에 private key키쌍(5685, 781)의 두 수를 곱해서 이것을 www.aabbcc.com 서버에게 건네준다. 
• 서버 이외에는 private key 값들을 모른다. 따라서 이 문자열은 암호화되었다.
• 나눗셈은 단순한 나눗셈이 아니라 위의 설명처럼 4만 년 걸리는 연산이라고 가정하겠다. 
• www.aabbcc.com 서버는 자기에게 방문하는 모든 클라이언트들에게 가장 먼저 이 암호화 스트링을 건네준다.
• 나눗셈은 어렵지만 곱셉은 쉽다. 위의 그림 속 과정처럼 두 개의 암호화된 스트링에 공개된 public값(2951)을 이용해서 곱셈 연산과 덧셈 연산을 수행한다.
• 16,777,216은 실은 2의 24승이다. 2진수나 16진수로 표현할 경우 맨 앞자리는 1이고 나머지 자릿수는 모두 0이다.
• '2의 24승과 x 16진수 문자열 값'은 뒤에 0들이 붙어있는 문자열 값으로 계산될 것이다.
• 문자코드인 유니코드는 보통 0x가 붙은 16진수로 표현하니까 이 표현에는 어색함이 없다.
• 클라이언트는 public key로 해독이 가능한 것을 확인하고 인증서버의 private key가 사용됐다는 것을 알 수 있다.
• 따라서 실제 문자열의 의미처럼 www.aabbcc.com은 인증서버가 정상 서버임을 보증하게 된다.
• 이 문자열을 파악했어도 나눗셈은 어려우므로 문자열 값에서 private key값을 알아내기란 매우 어렵다.

 

이렇게 위에 보이는 암호화된 문장을 인증서라고 부른다. 비대칭 암호 알고리즘을 이용해 대상이 신뢰받을 수 있는지 없는지를 확인하는데 쓰이기 때문이다.

 

3. 비대칭 암호 알고리즘의 한계와 대칭 암호 알고리즘

• 보통 비대칭 암호 알고리즘을 통해 대용량의 데이터를 주고받진 않는다.
• 비대칭 암호 알고리즘은 cpu가 해줘야 하는 일에 비해 느리고 효율이 떨어지기 때문이다.
• 보통은 대칭 알고리즘이 훨씬 빠르고 효과적인데 이는 암호화하고 복호화하는데 같은 key값을 쓰는 알고리즘이다

 

대화를 주고받는 서버와 클라이언트가 서로 같은 key 값만 안전하게 공유할 수 있다면 대칭 알고리즘을 쓰는 게 훨씬 유리하다.

따라서 이 대칭 키값을 안전하게 공유하는데만 비대칭 알고리즘을 사용한다. 방법은 아래와 같다.

• 인증서버가 발급한 www.aabbcc.com 서버의 인증서 문자열에는 사실 한 문장이 더 들어있다.
• 그 문장은 "www.aabbcc.com서버의 자체 publice key는 (6789, 16,777,216)이고, 서버가 사용하는 대칭 암호 알고리즘은 뭐뭐입니다"이다
• 인증서를 해독하고 www.aabbcc.com을 신뢰할 수 있게 된 클라이언트는 자기도 클라이언트 public key와 private key를 만든다.
• 클라이언트는 자신의 public key를 www.aabbcc.com의 public key 6789로 곱해서 암호화한다.
• 이 암호 값을 www.aabbcc.com 서버가 받으면 서버용 pirvate key로 암호를 풀어서 클라이언트의 public key를 확인한다.
• 따라서 이 클라이언트의 public key는 서버만 확인할 수 있다.
• www.aabbcc.com 서버는 이 클라이언트의 public key를 이용해서 앞으로 서버와 클라이언트가 사용할 대칭 암호화 알고리즘의 키값을 암호화하고 전송한다.
• 따라서 이 대칭 암호화 알고리즘의 키값은 클라이언트만 확인할 수 있다.
• 클라이언트는 앞으로 많이 쓰게 될 대칭 암호화 알고리즘의 키값을 잘 저장해 둔다.
• 이제 서버와 클라이언트 사이의 모든 대화는 정해진 대칭 암호화 알고리즘으로 암호화된다.
• 이 암호화 채널 위에서 html 문서를 주고받는 http 프로토콜이 돌기 시작하면 이것이 https이다.

 

이렇게 https 프로토콜의 보안에 관련한 사항에 대해서는 CA서버가 그 중추적인 역할을 하게 된다.

 

CA 서버(인증서버)는 브라우저를 만드는 회사들(Explorer, Chorme 등)이 사전에 심의를 거쳐서 CA와 CA의 Public key 목록을 브라우저에 넣어둔다고 한다. 브라우저들 사이에서 이런 CA 관련 목록을 정적으로만 관리하는지, SSL 프로토콜(TLS 프로토콜이라고도 불린다)의 추가적인 기능을 통해 동적으로 업데이트가 되는지는 잘 모르겠다.

 

사실 암호 알고리즘은 정수론부터 시작해서 군, 환, 체라는 수체계를 다루는 현대 대수학을 공부해야 정확히 이해할 수 있다. 이를 통해 역산을 매우 어렵도록 만들어 줌으로서 키값이나 원본 내용물을 숨겨주는 수학적, 논리적 도구들에는 매우 다양한 것들이 있으며 어설픈 나눗셈 따위가 낄자리는 없음을 알게 된다. 이는 매우 정교하고 복잡하지만 그와 동시에 조금은 아름답게 동작한다. 차후 때가 오면 이와 관련한 포스팅을 천천히, 차근차근, 오랜 시간에 걸쳐하도록 하겠다.