[CIA와 대칭키, 비대칭키]

CIA

보안 목표와 요구사항을 달성하기 위한 3요소, 즉 보안 시스템, 정책, 암호화, 인증 등의 기준 목표이자 기준

 

1. Confidentiality (기밀성)

허가되지 않은 사람이 데이터를 열람할 수 없도록 보호하는 것이다.

 

예시:

*  비밀번호, 개인정보, 기밀 문서 등을 암호화 하여서 기밀성을 지킨다.

*  접근 제어를 통해 인가된 사용자만 접근 가능하게 한다.

 

2. Integrity (무결성)

데이터가 위조, 변조되지 않았다는 것을 보장하는 것

 

예시:

*  파일이나 데이터가 전송 중 누락되거나 바뀌지 않았는지 확인

 

3. Availability (가용성)

필요한 사람이 필요할 때 정보나 시스템을 사용할 수 있어야 한다.

 

예시:

*   서버 다운 방지 (백업, 이중화, 장애 조치)

 

*   DDOS 방어

*   서비스가 24시간 정상 작동하도록 유지

 

 

A나라        C나라       B나라    
(동맹          탈취자      동맹)

이렇게 A나라와 B나라가 서로 동맹이며 C나라는 해커 or 탈취자라고 가정해보자.

A에서 B로 문서를 전달하는 와중에 c나라에서 문서를 낚아챌 수가 있다.

이 경우 문서를 열람이 가능하다면 기밀성이 위배된 것이다. 

만일 문서가 위조가 된다면 무결성 또한 위배되는 것이다.

결국에는 문서가 탈취된 순간부터 B는 온전한 정보의 사용이 불가하므로 가용성이 위배되는 것이다.

 

여기서 문서를 암호화를 한다면 가용성이 깨질 수도 있어도 기밀성을 유지할 수 있다.

이 암호화 해제에 필요한 것이 어떠한 키값이라고 해보자.

 

하지만 여기서 또 문제점이 하나 생긴다. 바로 이 키값에 대한 전달문제이다.

그러므로 A는 B에게로부터 무사히 잘 받았다는 응답이 필요하다.

그런데 이 잘 받았다는 것에 대해서도 명확한 출처가 필요하다. 이유는 이 응답마저 C가 가로채서 잘받았다고 위조를 할 수 있기 때문이다.

 

결국 두가지 문제를 해결해야 한다는 것이다.

1. 암호화   2. 해당 정보에 대한 명확한 출처

 

여기서 비대칭키와 대칭키에 대한 개념이 등장한다.

 

✔ 비대칭키 ( Asymmetric Key Encryption )

암호화와 복호화에 서로 다른 키를 사용하는 방식이다.
이때 사용하는 두 키는 **공개키(Public Key)**와 **개인키(Private Key)**로 구성된다.

 

 

공개키는 외부에 유출되어도 상관없다. 하지만 개인키는 반드시 자신만이 가지고 있어야 한다.

여기서 공개키로 암호화를 했다면 개인키로 복호화 하여야 한다.

이런 방식에는 개인키를 가진 사람만이 

읽을 수 있도록 초점을 둔것이다. 개인키를 가진 사람만이 복호화가 가능하므로 기밀성을 지킬 수 있다.

 

만약 개인키로 암호화를 했다면?

그렇다면 공개키로 복호화가 가능하다는 것인데 이러면 보안 문제가 있지 않나? 공개키는 누구나 

가질 수 있는 것인데 라고 생각할 수 있다.

하지만 이 방식은 기밀성보다는 명확한 출처 표기에 대해 초점을 

두고 있다.

공개키로 누구나 열람할 수 있지만 반대로 생각해보면 어떠한 문서를 복호화 하려할때

A의 공개키로 열리지 않는다면 A의 개인키로 암호화 했다는 것이 아니라는 반증이다.

즉, 신뢰할 수 있는 출처로부터 온 것이 아니다. 

 

장점 :

- 공개키만 공유해도 안전한 통신이 가능하다. 

- 개인키를 유출하지 않으면 매우 높은 보안 수준 유지

 

단점 : 

- 연산이 복잡하고 속도가 느림

- 대량 데이터 처리에 부적합

- 암호화에 **리소스(CPU, 메모리)**가 많이 듦

 

✔ 대칭키(Symmetric Key Encryption)

암호화와 복호화에 동일한 키를 사용하는 방식이다.
즉, 같은 키로 잠그고, 같은 키로 푼다.

 

 

 

장점 :

- 암호화/복호화 모두 같은 키를 사용하기 때문에 매우 빠르다

- 구조가 단순하고 구현이 쉬워, 성능이 중요한 환경에서 유리하다

 

단점 : 

- 키가 유출되면 모든 메시지 노출됨

- 서로 공유해야 하는데 안전하게 보내기 힘듦

-  같은 키를 공유해야 하기 때문에  한 번은 키를 전달해야 한다. 이 때, 키를 전송하는 과정에서 정보를 탈취       당할 위험성이 있다.

 

하지만 실생활에서는 둘이 혼합된 방식을 많이 사용한다. 보편적인 예시로 HTTPS 프로톨이 있다.

 

 

HTTPS에서 대칭키와 비대칭키를 적용한 흐름

 

1. 클라이언트가 서버에게 요청을 보냄

 

2. 서버가 공개키를 보낸다. (디지털인증서 + 공개키) ,인증서는 일반적으로 RSA/ECC 공개키

 

3. 클라이언트가 인증서가 신뢰할 수 있는 CA(인증기관) 에서 발급되었는지 확인

 

4. 클라이언트가 대칭키 (세션키) 를 생성하고 이 대칭키(세션키)를 비대칭키로 암호화한다.

- 공개키로 암호화 한다. 서버만 개인키로 복호화가 가능하다.

 

5. 서버는 개인키로 받은 암호화된 세션키를 복호화한다.

- 클라이언트와 서버는 이제 동일한 세션키를 갖게 된다.

 

6. 이후 모든 데이터는 대칭키로 암호화 하여 통신한다.

 

 

* 서버가 보내는 인증서(SSL/TLS 인증서)는 CA(인증기관)의 전자서명이 있는데 

이 전자서명을 CA의 공개키로 검증한다. ( 출처 검증 의도)

* 클라이언트가 세션키를 안전하게 전달하기 위해 공개키로 암호화 -> 서버에서 개인키로 복호화 (기밀성 확보)

 

 

여기서 브라우저를 털면 세션키를 탈취 할 수 있으니 위험한거 아닌가? 라는 생각을 옛날에 했는데

이거는 어떻게 보면 컴퓨터가 해킹당했다는 것이다. 즉, HTTPS의 보안 범위를 벗어난 것....

HTTPS는 데이터 전송과정에서의 탈취와 위조를 방지하는 것이 목표이지

브라우저가 털리는 건 브라우저 or 시스템 수준에서의 보안 취약점이다.

 

 

인증과 암호화를 수행하는 HTTP에서의 프로토콜로 SSL 과 TSL  과 있다.

 

- HTTPS

ssl/tls 를 사용하는 대표적인 프로토콜

안전한 메시지 송수신을 위해 개발되었다.

 

<https의 동작과정>

1. tcp 쓰리 웨이 핸드셰이크 (https://develop-actas.tistory.com/102  참조) 

2. tls 핸드셰이크

클라이언트의 초기 메시지에 tls 버전 및 사용 가능한 암호화 알고리즘 , 해시 함수 등을 포함하여 전달

서버는 제시된 정보들을 선택하는 메시지를 보낸다.

클라이언트-서버가 주고받으며 암호화 통신을 위해 사전 협의해야 할 정보들이 결정된다.

여기서 사용가능한 암호화 방식과 해시함수를 암호 스위트라고 한다.

tls 핸드셰이크에서 Certificate 메시지와 CerificateVerify 메시지를 통해 인증서와 검증을 마친다.

 

3. 암호화된 메시지를 송수신한다. 

 

 

 

정리

* A -> B 전송시에 0023이라는 데이터조각을 B의 공개키로 암호화, 그 후 A의 개인키로 암호화

B가 받아서 A의 공개키로 복호화 ---> A가 발급한게 확실하군.B는 또다시 B의 개인키로 복호화 ---> 보안성이 확실하군.