HTTPS를 위한 간단한 사전 지식

암호학에 대한 이론이 없으면 생각보다 관련 개발하기가 힘들다.  

 

또한 이는 자주 접하는 부분도 아니기 때문에 공부를 해도 까먹기 마련이다. 

 

다시 한번 기본 개념을 빠르게 훑어보자!

 

 

Checksum

 

데이터의 오류 여부 확인 방법으로 널리 사용된다. 

 

데이터 원본을 클라이언트에게 전송했는데, 이 데이터의 원본과 사본이 완벽하게 일치하는지 확인하는데 비교하는 방법론이다. 

 

원본 + 체크섬(원본 데이터로 만든 데이터)을 같이 보내서 클라이언트에서 재 검사를 통해 만든 체크섬과 받은 체크섬 값과 비교하여 같으면 원본 데이터이고 같지 않으면 위조 데이터로 취급한다.

이는 일정 자릿수를 정하고 범위를 넘는 자리올림은 버려서 자릿수를 유지한다. 

 

하지만 체크섬을 위조한다면 클라이언트에서는 위조 여부를 알지 못한다. 이를 대안하기 위해 나온 개념이 Hash이다.

 

Hash 함수의 특징은 "단방향성"이다. 또 입력 값의 크기와 상관없이 결과 값의 길이가 일정하다.  

 

나머지 연산을 생각하자.  해시의 원본 데이터를 역추적하고 싶은데 원본 값 2가 도출됐다고 가정하고 그 산술식은 x % 3이다. 이 경우 x를 구할 수 있을까? 

 

3으로 나누었을 때 2가 나머지로 남는 수는 무수히 많다. 즉 역추적이 불가능하다. 또한 나누는 숫자에 따라 길이가 한정된다. 0~2까지 그 범위가 고정된다. 

 

물론 실제론 경우의 수가 굉장히 범위가 넓어야 한다. 또한 해시 충돌 방지를 위해 중복되는 값이 적어야 한다.

이것이 좋은 해시 알고리즘의 척도이다.

 

이러한 특징은 데이터의 위변조를 증명하기 위해 사용될 수 있다.

 

그럼 Hash 알고리즘은 무엇이 있을까?

 

MD-5는 경우의 수가 매우 적어서 패스워드 단방향 암호화에 사용하면 안 된다.

rainbow table을 이용해 원본 데이터에 대해 여러 번 시도하면 같은 해시 값이 나올 수 있기 때문에 단방향 암호화는 안전하지 않다. 그래서 보통 salt 값을 사용해 길이를 늘여서 사용하기도 한다.  그러면 해쉬 결괏값이 노출된다고 해도 일치한 값을 찾기가 매우 어려워진다. 

 

대안으로 SHA-128. 256, 384, 512.. 를 많이 사용하며 이는 숫자가 커질수록 경우의 수가 커지는 것을 의미한다.

 

 

대칭키 (Symmetric key)

 

키 하나로 암호화/복호화를 모두 수행하는 방식이다. 

DES, 3 DES, SEED-128, ARIA, AES-128, AES-256 알고리즘이 유명하다.

 

대칭키는 XOR를 사용한다.

평문을 key로 XOR 연산하여 나온 암호문이 있고 그 암호문을 key로 XOR 연산하면 평문이 나오는 구조이다.

1	0	0	1	0	1	0	0
1	1	0	1	0	0	0	1
0	1	0	0	0	1	0	1

물론 XOR만 하지 않지만 이해하기 위해 간단하게 설명했다. 

위 표에서 첫 번째 줄은 평문이고 두 번째 줄을 KEY라고 한다. 세 번째 줄은 1,2번째 줄을 XOR 하여 나온 암호문이다. 

2,3번째 줄을 XOR 하면 첫 번째 줄이 도출된다. 

 

여기서 볼 것은 key의 길이이다.  8비트로 나올 수 있는 경우의 수는 256가지 연산 수는 XOR 한 가지 따라서 key값의 유출되면 평문을 해킹하는 것은 매우 쉽다. 따라서 key의 길이에 따라 보안성이 증가된다.

 

 

비대칭키 (Asymmetric key)

 

한 쌍의 키가 서로 상호작용하는 구조를 갖는다. 우리에게 친숙한 Public key와 Private key로 나누어진다.

이는 PKI(Public Key Infrastructure) 기술의 근간을 이룬다.

RSA-2048, ECC 알고리즘 등이 있다.

 

 

비대칭 키는 평문을 특정 수로 제곱을 진행한 이후 특정 수로 나눈다.  특정 수를 Modulus라고 한다.

제곱되는 수와 나눠지는 수를 퍼블릭하게 우리는 공개한다. 그 결과는 암호문이다.

이때 우리는 소수를 활용한다. 소수를 사용해야 분포도와 중첩 수가 적어진다.

자바에서도 객체의 해시 값을 생성하는 로직도 잘 보면 31이라는 소수로 값을 계산하는 것을 확인할 수 있다.

이후 복호화를 하기 위해 결과 값에 프라이빗 키의 값에 대해 제곱을 진행한 후에 공개된 Modulus로 계산을 진행하면 평문이 나온다. 

 

여기서 주목해야 하는 것은 암호문에 프라이빗 키를 제곱하는 순간 매우 큰 수가 도출된다. 큰 수라는 것은 정말 수많은 경우의 수가 있다는 것을 의미하기에 보안적으로 안정성을 부여할 수 있다. 물론 이건 현재 기준이다. 미래에 이를 전수 조사할 수 있는 컴퓨터가 나오면 무력화돼버린다. 

 

디지털 서명

 

이는 평문을 위변조, 부인 방지를 위해 private key로 암호화를 진행해버린다.  그리고 인증 대상에게 해시 결과와 public key를 같이 준다.  이를 public key로 해시 결과를 복호화하여 해시 값을 비교한다. 

 

 

 

인터넷 환경

 

결국 키라는 것도 어떠한 정보 그 자체이다. 이 키를 탈취당했다면 비대칭키, 대칭키 등 의미가 없어져버린다.  그런데 인터넷 환경에서 key를 전달하는 과정을 어떻게 처리할 것인지 생각해볼 필요가 있다.

 

서버에 암호문을 전달하는 과정에서 key를 같이 전달해야 하는 데, key가 탈취당하면 정보가 노출된다. 

 

따라서 서버와 클라이언트는 보안 터널을 통해 전달하기로 합의를 하고 서로 공개키를 교환한다. 

이 공개키는 외부에 노출되어도 상관없는 키이다. 

이 상태에서 클라이언트 혹은 서버가 전달해야 하는 정보가 있으면 주고받은 퍼블릭 키로 해당 문서를 암호화하여 전달한다. 

이 문서를 복호화할 수 있는 대상은 바로 프라이빗 키를 통해서만 가능하다. 

 

즉 비대칭키를 사용해 key전달 문제를 해결하였다.

 

 

 

성능적으로 보자

 

key 생성에 드는 비용은 생각보다 어마 무시하다. sha-256. 512... 등등 대칭키 알고리즘 뒤에 붙는 숫자는 생각보다 적다. 그런데 비대칭키인 rsa-2048, 4096, 8192... 알고리즘 뒤에 붙는 숫자는 왜 이리 클까?

 

이는 공개키를 노출한다는 점이다. 공개 키를 노출함으로 써 프라이빗 키를 어느 정도 유추가 가능해지는데

이를 막기 위한 대칭키 보다 더 큰 경우의 수가 필요해졌다.

 

그래서 비대칭키를 만드는 과정은 대칭키보다 상대적으로 무거운 작업이 될 수밖에 없다.

 

효율 극대화를 위해 인터넷 환경에서는 혼합으로 사용한다. 

 

대칭키의 문제는 뭐다? 바로 키를 전달하는 과정이다. 비대칭키의 문제는 뭐다? 바로 성능적으로 이슈가 있는 것이다.

 

그럼 우리는 대칭키를 서버 쪽의  공개키로 암호화해서 보내면 보안성이 증가되지 않을까? 

 

서버에서는 자신의 프라이빗 키로 대칭키를 복호화한다. 

 

이는 중간에 암호화된 대칭키를 서버 외에는 복호화할 수 없는 것을 의미한다.  이러한 방식으로 서로 간의 대칭키를 사용하여 정보를 전달해도 key가 노출되지 않아서 성능적으로 빠르게 암호문을 전달할 수 있는 것이다.

 

여기에는 하나의 의문 제기를 할 수 있다. 서버가 보내준 공개키를 믿어도 되는지에 대한 의문이다.

클라이언트는 반드시 서버가 보내준 공개키를 검증을 해야 한다!

 

서버는 키에 대한 생성과 유효기간에 대해 고민해봐야 한다. 키 생성은 매우 전산자원이 많이 드는 작업이다. 

따라서 이를 일회용으로 쓰고 버린다는 것은 매우 비효율 적이다. 그래서 보통 직접 키쌍을 만드는 경우에는 1회 만들고 갱신주기를 정해 갱신일마다 키를 새로 만든다. 

 

그렇지 아니한 경우에는 RA에게 키와 쌍을(인증서) 구매한다.  그럼 RA에서는 회사를 검증한다. 

검증 이후 CA에게 전달한다. RA에는 사실상 등록 대행업체라 보면 된다.  

 

이후 퍼블릭 키와 프라이빗 키가 나오면 RA는 퍼블릭 키에  수많은 정보와 무결성을 위한 해시 결과를 넣는다. 

이러한 형식을 X.509라고 한다.  이제 이걸 우리는 인증서라고 하는 것이다.

 

X.509 형식을 따르는 퍼블릭 키 + 프라이빗 키를 한 세트로 묶어서 구매한 업체에게 전달하는 것이다. 

근데 이걸 웹에서 사용하니까 우리는 SSL/TLS 인증서라는 이름으로 부르는 것이다.

 

그럼 서버에는 X.509 인증서와 프라이빗 키를 가지고 있다. 

클라이언트가 https요청을 하면 서버에서 퍼블릭 키 대신 인증서를 전달한다. 

 

그럼 클라이언트는 인증서를 어떻게 확인해야 될까?

 

예를 들면 우리가 사용하는 Window 운영체제의 업데이트 시 CA에게 기관 인증서를 MS사가 받아서 클라이언트 PC에 기관 인증서를 설치해버린다.  그래서 기관 인증서를 통해 서버 인증서를 검증하는 것이다.

 

어떻게  검증할까? 

 

사실 X.509 인증서 형식에는 디지털 서명 값이 존재한다.

퍼블릭 키와 부가 정보를  CA의 프라이빗 키로 디지털 서명한 이후 인증서에 포함시킨다.  

기관 인증서라는 것이 사실 CA의 공개키와 다름없다. 

 

따라서 클라이언트는 CA의 공개키를 가지고 있고 서버는 CA의 프라이빗 키로 전사서명을 한 값을 전달해주기 때문에 이를 CA 공개키를 사용한 복호화 여부에 따라 검증이 가능해지는 것이다.

 

cms 창을 열고 certmgr을 쳐보자. 우리 PC에 설치되어 있는 기관 인증서(CA의 퍼블릭 키)를 볼 수 있을 것이다.

 

CA는 Certification AUthority약자로 한국에는 NCA, yessign(금융결제원)등이 있다. RA는 등록기관으로 여러 기업들이 존재한다. 또 CA위에 있는  PAA(과학기술정보통신부), PCA(KISA)와 같은 여러 PKI 인증체계가 있다.