[보안] 단방향, 양방향 암호화와 대칭키, 비대칭키

정보관리기술사 스터디 TOPIC 중 해당 주제가 헷갈려서 정리해둔다.
아래 링크의 게시물 시리즈가 굉장히 잘 정리되어 있는 편이고, 나는 해당 내용을 압축하여 살을 붙였을 뿐이다.
TLS(SSL) - 1. TLS의 암호화 방식(대칭키, 비대칭키) (tistory.com)

TLS(SSL) - 1. TLS의 암호화 방식(대칭키, 비대칭키)

---

단방향 암호화와 양방향 암호화

단방향 암호화(해시)

비밀번호와 같은 정보는, 해당 비밀번호가 맞냐, 맞지 않냐의 여부만 중요하기에, 복호화가 필요없다.
이와 같은 정보의 경우, 압축 효과가 있으면서 원래 키와 1대1 대응이 가능한 해시 알고리즘을 사용한다.
즉, 원본이 같으면 해시결과도 같은 것을 이용한다.
보안을 위해 데이터베이스에는 해시된 결과만을 저장한다.
이와 같은 알고리즘은 sha256같은 것이 있다.

양방향 암호화(해독)

반대로 원래 정보를 복원할 필요가 있는 경우, 정보의 손실이 일어나는 압축 등을 사용해서는 안된다.
이 경우 해독이 가능한 알고리즘을 사용해야 한다.

대칭키(비밀키) 암호화

서로간에 암호화 및 복호화가 가능한 키 하나를 공유한 뒤, 상대한테 보낼 때, 해당 키로 암호화해서 보내는 것이다.
받은 사람은 해당 키로 복호화가 가능하다.
단점은 키가 하나라 털릴 수 있고, 상대방마다 다른 키를 유지한다면 관리하기 곤란하다.
aes256과 같은 알고리즘이 있다.

대칭키(비밀키) 암호화는 키를 하나 사용함

비대칭키(공개키) 암호화

비대칭키 암호화 방식은 반대로, 서로 비밀키를 하나씩 갖고, 상대에게 공개키를 주는 것이다.

• 상대는 공개키로 암호화해서 보내고, 나는 비밀키로 암호화해서 보낸다.
• 상대는 공개키로 해독 가능하고, 나는 비밀키로 해독 가능하다.

비대칭키(공개키) 암호화는 키가 두 쌍 필요함

rsa256과 같은 알고리즘이 있다.
 
SSL/TSL은 내부적으로 위에 소개한 3가지 요소를 전부 사용한다.

---

 

SSL / TLS와 인증서

실제로 SSL / TLS는 비대칭키 암호화 방식처럼 공개키 / 비밀키 두쌍을 사용하지 않는다.
실제로는 공개키/비밀키 한 쌍과, 대칭키 한 쌍을 사용하게 된다.
 
더 자세한 내용은 아래 링크를 참조하면 이해가 잘 된다.
아래 내용도 링크의 내용을 요약정리헀을 뿐이다.
 
TLS(SSL) - 2. 인증서, CA, SSL 인증서를 통해 서버를 인증하는 방법 (tistory.com)

TLS(SSL) - 2. 인증서, CA, SSL 인증서를 통해 서버를 인증하는 방법

TLS(SSL) - 3. Handshake (tistory.com)

TLS(SSL) - 3. Handshake

 
인증서가 필요한 이유는, 서버 자체가 믿을 수 없는 바다이야기 같은 사이트 일 수 있기 때문이다.
믿을 수 있는 상위 기관에게 인증받는 작업이 필요하다.
이런 최상위 인증기관을 ROOT CA라고 하며, 해당 인증서들 간 연결관계를 인증서 체인(Certification Chain)이라 한다.
대부분의 인증기관의 인증서는 브라우저에 미리 포함되어 있으며, 필요한 경우 추가로 등록할 수 있다.
이 말은, 최상위 인증기관에게 인증받을 수 있으면 유효한 인증서임을 의미한다.
최상위 인증기관의 인증서는 self-signed된 인증서라 한다.
 
인증서에는 다음과 같은 정보들이 존재한다. (해당 인증서는 서버에서 내려준다.)

• 발급자
  • 브라우저에 인증받은 CA들의 인증서(공개키)가 이미 존재함
  • 인증서 체인을 통해 해당 CA의 인증서로 인증가능하면 유효한 인증서다.
• 공개키
• 서명
• 지문

티스토리 인증서 체인

해당 인증서 간의 관계는 서명으로 연결되는데, 이는 다음과 같다.

1. 자신의 공개키를 해시한다. 이를 지문이라 한다.
2. 지문을 상위 기관의 비밀키로 암호화한다. 이를 서명이라 한다.
3. 상위 기관의 공개키는 브라우저가 이미 알고 있다.
4. 브라우저는 상위 기관의 공개키를 알고 있으므로, 서명을 복호화하여 지문과 일치여부를 판단할 수 있다.

self-signed는 자신의 인증서를 해시한 후(지문), CA가 아닌 자신의 비밀키로 암호화 하여 서명으로 등록한 것을 의미한다.
이 의미는, 발급기관의 인증서가 이미 Root CA에 의해 인증받았으면 발급기관의 공개키만 있으면 신뢰여부를 결정할수 있다는 것이다. 이 인증서들은 브라우저에 이미 있고 말이다.

인증서 체인

발급자 정보를 통해 self-signed 여부를 알 수 있음

즉, 인증서 체인을 따라서(CN을 이용해 인증서 발급자를 찾아 타고 타고 올라간다 - 공개키로 해독) 식별 가능하면, 유효한 인증서인 것이다.

인증서 발급자를 알 수 있는 CN Name

이를 한 장으로 요악하면 다음과 같이 될 것이다.
인증서 체인의 가장 아래인 라온시큐어의 공개키, 지문, 서명은 다음과 같은 관계가 있다.
우리는 Thawte의 공개키를 알고 있으므로, 서명으로 지문의 일치 여부를 알 수 있다.

라온시큐어 키체인

지금까지 내용 중에는, 사실 서버와 클라이언트 간 공개키, 비밀키는 한 쌍만 존재한다.

• 즉, 비밀키는 서버에만 있으면 되고,
• 공개키는 서버가 주는 인증서에 포함되어 있다.

사실은 이렇습니다.

그러면, 클라이언트가 보내는 정보는 어떻게 암호화할까?
사실, 서버와 클라이언트 간 SSL 인증이 완료된 후에는, 부하를 줄이기 위해 대칭키 암호화 방식을 사용한다.

• 클라이언트는 서버의 공개키로 대칭키를 암호화 하여 서버에게 보낸다.
• 서버는 자신의 비밀키로 이를 복호화 하여 클라이언트의 대칭키를 알아낸다.

---

요약

1. 서버는 클라이언트에 인증서를 준다.
2. 인증서는 상위 기관의 인증을 받는다. (비대칭키)
   • 지문은 서버의 공개키를 해시한 것이다.
   • 서명은 지문을 상위 기관의 비밀키로 암호화한 것이다.
   • 인증서의 유효여부를 확인하기 위해, 서버의 서명을 상위기관의 공개키로 복호화해 지문과 일치하는지 확인한다.
     • 지문 == 서명복호화 일치여부
3. 인증서가 유효하면, 클라이언트는 서버의 인증서에 들어있는 공개키로 자신이 사용할 대칭키를 암호화한다.
   • 그리고 데이터를 해당 대칭키로 암호화하여 서버에 전송한다.
4. 서버는 자신의 비밀키로 해당 대칭키를 복호화한다.
   • 그리고 해당 대칭키를 이용해 데이터를 암호화하여 클라이언트에 전송한다.

이처럼 SSL 통신은 해시(단방향 암호화)와 대칭키, 비대칭키(양방향 암호화)가 모두 사용되는 복잡한 기술이다.