네트워크 - 대칭키 공개키

CS스터디를 진행하던 중에 대칭키 공개키 주제가 나왔다. 들어보기만 했던 단어여서 공부해 보았다.

 

이 둘은 암복호화와 관련된 용어이다. 암복호화는 암호화(Encrpytion)와 복호화(Decrpytion)의 줄임말이다. 

이 변환은 특정한 암호화 알고리즘을 사용하고, 이 알고리즘은 대부분 키라는 특정한 값을 이용해 동작합니다. 암호화된 정보는 키 없이는 원래의 정보로 해독할 수 없어 정보의 보안을 유지할 수 없습니다.

 

반면, 복호화는 암호화된 정보(암호문)를 다시 원래의 정보(평문)로 변환하는 과정을 말합니다. 복호화도 암호화와 마찬가지로 특정한 알고리즘과 키를 사용합니다. 암호화에서 사용된 동일한 키를 사용하여 암호문을 다시 평문으로 변환하는 것이 일반적입니다.

 

따라서, 암호화와 복호화는 정보 보안에서 중요한 역할을 하는데, 이를 통해 정보가 전송 중에 도청되더라도 도청자는 암호화된 데이터만 볼 수 있고 원래의 정보를 이해할 수 없습니다. 또한, 암호화된 정보는 원래의 정보로 변환하는 키 없이는 복호화할 수 없으므로 정보의 안전성을 높이는 데 기여합니다.

 

대칭키 암호화 방식은 암복호화에 사용하는 키가 동일한 암호화 방식을 말합니다.

공개키 암호화 방식은 암복호화에 사용하는 키가 서로 다르며 따라서 비대칭키라고도 합니다.  따라서 공개키 암호화에서는 송수신자 모두 한쌍의 키(개인키, 공개키)를 갖고있게 됩니다.

 

더 살펴보기 이전에 보안의 3요소에 대해 간단히 정리하고 가보자.

• 기밀성: 인가받은 사용자만 정보 자산에 접근할 수 있음을 보장하는 것
• 무결성: 권한을 가진 사용자에 의해 인가된 방법으로만 정보를 변경할 수 있음을 보장하는 것.( 즉 메시지 내용이 중간에 변조되지 않아야 함.)
• 효율성: 정보에 대한 접근과 사용이 적시에 확실히 보장하는 것. (너무 큰 메시지를 전달하지 않도록 해야 함.)

대칭키

암호화와 복호화에 같은 암호키(대칭키)를 사용하는 알고리즘입니다.

동일한 키를 주고받기 때문에, 매우 빠르다는 장점이 있습니다.

대칭키를 사용하는 알고리즘은 통신과정에서 키를 교환하게 됩니다. 이 교환과정에서 키가 탈취될 수 있는 문제도 있고 사람이 증가할수록 전부 따로따로 키교환을 해야하기 때문에 관리해야할 키도 방대해집니다. 이는 더욱 탈취위험 가능성을 증가시킵니다.

따라서 장점과 단점을 정리하자면 아래와 같습니다.

장점

• 구현이 용이하다.
• 데이터를 암호화하기 위한 연산이 빨라 대용량 데이터 암호화에 적합하다.
• 기밀성을 제공한다.

단점

• 강한 보안을 위해 키를 주기적으로 교환해주는 것이 좋다.
• 키 탈취 및 관리가 어렵다.
• 무결성 지원이 부분적으로만 가능하다.
• 부인 방지 기능을 제공하지 못한다

공개키(Public Key)/비대칭키(Asymmetric Key)

암호화와 복호화에 사용하는 암호키를 분리한 알고리즘. 

대칭키의 키 분배 문제를 해결하기 위해 고안됨. (대칭키일 때는 송수신자 간만 키를 알아야하기 때문에 분배가 복잡하고 어렵지만 공개키와 비밀키로 분리할 경우, 남들이 알아도 되는 공개키만 공개하면 되므로)

자신이 가지고 있는 고유한 암호키(비밀키)로만 복호화할 수 있는 암호키(공개키)를 대중에 공개함.

 

공개키 암호화 방식 진행 과정

1. 수신자인 B가 공개키/ 개인키 쌍을 생성한다. 

2. 공개키를 공개하고, 개인키는 B 본인이 소유하고 있는다. 

3. 송신자인 A가 B의 공개키를 가져온다.

4. A가 B의 공개키를 사용해서 데이터를 암호화한다.

5. 암호화된 데이터를 B에게 전달한다.

6. B는 암호화된 데이터를 B의 개인키로 복호화한다.(이때 개인키는 B가 그대로 갖고있으므로 탈취 가능성이 낮다.)

 

장점

• 부인방지 기능을 제공합니다.
• 키 분배 및 키 관리가 용이합니다.
• 기밀성, 무결성을 지원합니다.
• 암호학적 문제를 해결할 수 있습니다.

 

부인방지

부인방지란 송신자나 수신자가 메시지를 주고 받은 사실을 부인하지 못하도록 방지하는 것을 말합니다.(사실상 무결성과 같은 의미입니다.)

 

예를 들어 A가 B에게 돈을 빌린 후 '차용증'에 서명했는데, 후에 A는 돈을 빌리지 않았으며 차용증 역시 자신의 서명이 아니라고 부인하는 경우를 생각해 볼 수 있습니다.(나쁜놈이죠..)

 

비대칭키/공개키 암호화 방식에서는 본질적으로 '발행자의 증명'과 동일한 절차로 이루어 집니다.

1. B는 A에게 개인키/공개키를 생성한 뒤 공개키를 공개하도록 요구한다.
2. B는 A에게 '문서'를 개인키로 암호화할 것으로 요구한다.
3. B는 이 '암호화된 문서'를 수령한다.
4. B는 '암호화된 문서'를 A 의 공개키로 해독하여, 이 문서가 A 의 개인키로 제대로 암호화 되었음을 검증할 수 있다.
5. 만약 해독되지 않는다면, 개인키-공개키 쌍이 맞지 않음을 의미한다. 공개한 공개키가 잘못되었거나, 다른 개인키로 암호화 했음을 뜻한다.

이 '암호화된 문서'는 A의 공개키로만 해독이 가능하므로, 이 '암호화된 문서'는 A만이 발행할 수 있다는 증거가 됩니다. 또한, 변조되지 않았음도 동시에 증명할 수 있습니다.

 

비대칭키/공개키를 사용한 암호학적 문제 해결

2가지 문제 데이터 보안과 인증을 해결할 수 있습니다.

공개키 암호화 -> 개인키 암호화: 데이터를 안전하게 전송할 수 있는 보안 관점. (데이터 보안의 관점. 누구나 암호화가 가능하나, 수신서버만이 복호화가 가능하다. 개인정보와 같은 데이터를 송신하는 상황은 이 방식대로 처리하는데 도움이 된다. 다만 부인방지가 보장되지 않는다.)

개인키 암호화 -> 공개키 암호화: 신뢰할 수 있는 단체라는 것을 인증하는 관점.(부인 방지. 누구나 복호화 할수있는 데이터이지만 송신 서버만이 암호화가 가능하다. 따라서 해당 데이터가 송신서버에서 암호화 했다는것이 증명된다.)

 

따라서 데이터 보안의관점에서 사용자가 데이터를 서버로 보내는 과정에서 개인정보와 같은 중요 데이터의 경우 암호화해서 보내야 합니다.

공개키 암호화 -> 개인키 암호화 방식을 따르게 됩니다.

인증관점 (아래의 그림을 참고하세요.)

디지털 인증서에는 모두가 신뢰할 수 있는 제삼자인 CA와 비대칭키 암호화가 필요합니다.

1. 클라이언트와 서버는 서로 확인 위해 Handshake 과정을 진행합니다. (이때 서버에서는 CA(공인 인증 기관같은 애들)에서 인증받은 인증서(CA의 개인키로 암호화된 전자서명)를 클라이언트로 보냅니다. 이 인증서는 CA에게 자신이 서버임을 증명하고 자신의 공개키가 서버의 공개키가 맞음을 인증하는 인증서입니다.) 
2. 사용자는 CA의 목록을 확인해 공인 인증 기관이 서명한 인증서인지 확인합니다. 
3. CA의 공개키를 이용해 해당 인증서를 복호화합니다.
4. 복호화에 성공하면 서버의 공개키를 얻습니다. 이렇게 얻은 서버의 공개키는 진짜 서버의 공개키가 맞음을 CA가 인증하는 것입니다. 따라서 클라이언트는 자신이 통신하고있는 상대가 의도한 서버가 맞음을 확인할 수 있습니다.

이러한 방식으로 공인 인증 기관으로부터 서명 받은 서버의 인증서가 공인 인증 기관의 공개키로 복호화가 가능하다는 것을 통해 해당 기관이 인증 받은 단체라는 것을 확인할 수 있습니다.

단점

1. 대칭키에 비해 암호화 복호화가 매우 복잡함.

(암호화하는 키가 복호화하는 키가 서로 다르기 때문)

 

2. 또한 절차가 많으므로 속도가 느릴수밖에 없습니다.

 

3. 하지만 이 방식은 Confidentiallity만 보장해줄 뿐, Integrity나 Authenticity는 보장해주지 못함.

- > 이는 MAC(Message Authentication Code)나 전자 서명(Digital Signature)으로 해결

(MAC은 공개키 방식이 아니라 대칭키 방식임을 유의! T = MAC(K,M) 형식)

 

MAC(Message Authentication Code)은 메시지의 무결성과 인증성을 검증하는 데 사용되는 암호 기술입니다. 이는 원본 메시지와 비밀 키를 결합하여 생성되며, 이렇게 생성된 MAC 값은 메시지와 함께 수신자에게 전송됩니다.

MAC을 생성하는 과정은 다음과 같습니다:

• 메시지를 보내려는 사람(발신자)은 메시지와 비밀 키를 MAC 함수에 입력합니다.
• MAC 함수는 입력된 메시지와 키를 기반으로 MAC 값을 생성합니다.
• 발신자는 이 MAC 값을 메시지와 함께 수신자에게 전송합니다.

MAC을 검증하는 과정은 다음과 같습니다:

• 메시지를 받은 사람(수신자)은 받은 메시지와 동일한 비밀 키를 MAC 함수에 입력하여 새로운 MAC 값을 생성합니다.
• 수신자는 이 새로 생성된 MAC 값과 메시지와 함께 받은 MAC 값을 비교합니다.
• 이 두 MAC 값이 일치하면 메시지가 중간에 변경되지 않았으며, 발신자가 유효한 키를 가지고 있음을 확인할 수 있습니다.

MAC은 대칭키 암호화 방식을 사용하므로, MAC을 생성하고 검증하는 데 동일한 키가 필요합니다. 이는 MAC이 메시지의 무결성뿐 아니라 인증성을 함께 보장한다는 점에서 중요한 특징입니다. 

즉, MAC은 메시지가 중간에 변경되지 않았음을 보장하는 동시에 메시지가 유효한 키를 가진 사람으로부터 왔음을 보장합니다.

하이브리드 방식?

대칭키와 공개키 암호화 방식을 적절히 혼합해보면? (하이브리드 방식)

SSL 탄생의 시초가 됨

1. A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하고 B에게 보냄
2. B는 암호문을 받고, 자신의 비밀키로 복호화함
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냄
4. A는 자신의 대칭키로 암호문을 복호화함
5. 앞으로 이 대칭키로 암호화를 통신함

 

즉, 대칭키를 주고받을 때만 공개키 암호화 방식을 사용하고 이후에는 대칭키 암호화 방식으로 통신하는 것입니다.

데이터 송수신을 한번 하고 난 이후로는 거추장스럽게 키관리를 하지 않아도 됩니다.😆