대칭키와 비대칭키 / 공개키와개인키 / PKI / SSL,TLS

By Bys on June 8, 2022

1. 파일 형식

PEM

PEM (Privacy Enhanced Mail)은 Base64 로 인코딩한 텍스트 형식의 파일

  • OpenSSH Private Key 
    -----BEGIN OPENSSH PRIVATE KEY-----
-----END OPENSSH PRIVATE KEY-----
  • 개인키 
    -----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
  • 인증서 
    -----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

CRT

인증서를 의미하는 CERT 의 약자로 보통 PEM 형식의 인증서를 의미하며 Linux에서 .crt 확장자를 많이 사용

CSR

CSR(Certificate Signing Request) 은 인증기관(CA)에 인증서 발급 요청을 하는 특별한 ASN.1 형식의 파일이며 그 안에는 내 공개키 정보와 사용하는 알고리즘 정보등이 들어 있음


2. 대칭키 암호화

대칭키 암호화는 이름에서 알 수 있듯이 암호화, 복호화 하는데 필요한 키가 동일한 경우다. A가 B에게 “이건 암호화된 문자야” 라는 메세지를 암호화 하여 전송하기 위해서 특정 키를 이용하여 암호화를 진행한다. 대칭키 구조에서 B는 “#123ABCDE!!~” 이렇게 암호화되어 받은 문자를 다시 복호화 하기 위해서는 A가 암호화 화는데 사용했던 동일한 키로 복호화를 진행하면 “이건 암호화된 문자야” 라는 메세지를 얻을 수 있다.

이렇게 암호화된 정보를 전달하고 확인하기 위해서는 송, 수신자 모두 동일한 키를 가지고 있어야 한다. 따라서 키를 안전하게 교환하는 것이 대칭키 암호화 방식에서의 가장 중요한 부분이다.

다만 대칭키 암호화는 비대칭키 암호화에 비해 복호화의 속도가 빠르다. 때문에 실제로는 비대칭키 암호화에서 대칭키암호화를 같이 사용하는 형태가 된다.


3. 비대칭키 암호화

비대칭키 암호화 또한 이름에서 알 수 있듯이 암호화, 복호화 하는데 필요한 키가 서로 다른 경우다. 대칭키와 다르게 비대칭키는 키가 개인키(Private Key)와 공개키(Public Key)로 나뉜다.

공개키로 정보를 암호화 (암호 모드)

A는 개인키와 공개키를 가지고 있고 개인키는 말 그대로 A개인만 가지고 있으며 A의 공개키는 누구에게나 공개가 되어있다.

  1. B는 A에게 암호화된 메세지를 전달하기 위해 A의 공개키를 네트워크 상에서 획득하여 메세지를 암호화하여 전달한다.
  2. A는 자신에게 전달된 암호화 메세지를 자신이 가지고 있는 개인키로 복호화하여 메세지를 얻는다.
  3. A의 공개키로 암호호된 메세지는 A의 개인키로만 복호화가 가능하므로 A외에는 누구도 암호화된 메세지를 들여다 볼 수 없다.

개인키로 정보를 암호화 (인증 모드)

  1. A는 자신의 개인키를 이용하여 정보를 암호화하여 특정 사용자에게 전달한다.
  2. B는 A의 공개키를 이용하여 정보를 복호화 할 수 있다.

하지만 여기서 생각이 드는 문제는 해당 정보는 C, D 라는 사람들 모두 A의 공개키를 활용하여 정보를 들여다 볼 수 있다는 것이다.
그렇다면 이 방식에서는 보안이 취약한 것이지 않을까? 이 방식은 ‘정보의 내용보다는 정보를 누가보냈는지’에 대한 초점을 두는 경우에 사용이 된다.

A의 공개키로 해당 암호화된 정보가 복호화 된다면 해당 메세지는 A가 보낸게 맞다는 의미가 된다.
따라서 이러한 기술은 데이터 제공자의 신원이 보장되는 전자서명 등에 사용 된다.

실제로는 위에서 언급한 바와 같이 대칭키 알고리즘과 비대칭키 알고리즘을 같이 사용한다.
Ex) B가 A에게 메세지를 보내는 과정

  1. B는 우선 임시 대칭키를 생성한다.
  2. 자신이 전달할 Plain text를 대칭키를 이용하여 암호화를 진행한다. (대칭키를 이용한 암호화/복호화 속도가 빠르기 때문)
  3. A의 공개키로 임시 생성한 대칭키를 암호화 한다.
  4. B는 암호화된 메세지와 암호화된 대칭키를 A에게 전달한다.
  5. A는 자신이 가지고 있는 개인키를 통해 암호화된 대칭키를 복호화 한다.
  6. 대칭키를 이용하여 Cipher text를 복호화 한다.

Plain Text의 크기가 커지면 비대칭키를 복호화하는 경우에는 위와 같은 방식보다 효율적이지 못하기 때문에 위의 프로세스를 사용하면 빠른 방식으로 복호화가 가능하다.


4. PKI (Public Key Infrastructure, 공개키기반구조)

PKI는 위에서 언급한 공개키 암호화와 전자서명을 사용할 수 있게 기반을 마련해둔 것이라고 이해를 하면 된다.
PKI(Public Key Infrastructure) 또는 공개키 기반구조는 디지털 증명서의 생성, 관리, 배포, 사용, 저장 및 파기, 공개키 암호화의 관리에 필요한 역할, 정책 등 일련의 절차들을 집합한 것이다.

  • PKI 구성요소

    1. 인증기관(CA, Certificate Authority): 사용자의 인증서 발급 및 관리 Ex) 한국정보인증(KICA), 금융결제원(yesSign), 한국진흥정보원(Sigate) 등

    2. 등록기관(RA, Registration Authority): 신원확인, 고객 데이터 유지 등 인증기관의 입증을 대행하는 등록기관.
      Ex) 은행, 증권사

    3. 디렉토리(Directory): 인증서 및 인증서 취소목록 등 PKI와 관련된 정보를 저장 및 검색하는 장소

    4. 인증서(Certificate): 공개키나 공개키의 정보를 포함하는 인증서 Ex) X.509 인증서

PKI는 공개키 기반 구조를 가지기 위해 비대칭키 암호화 방식에서 CA라는 개념을 등장 시킨다.

  • CA의 등장 배경
    공개키 암호화에서 개인키는 오로지 개인이 소유하고 있어야 하고, 반면 공개키의 경우 다른 사람들도 모두 사용을 해야하는데 이것을 어떻게 구현할 수 있을까?
    일반 네트워크의 저장소 어디엔가 공개가 되기에는 누군가가 공개키를 조작하는 문제가 발생할 수 도 있다.

    1. A는 B와 암호화 통신을 하고 싶다.
    2. B의 공개키를 이용하고자 하는데 중간에 해커가 끼어들어 B의 공개키를 가로채고 해커의 공개키를 B의 공개키인 것처럼 속여 A에게 전달한다.
    3. 이를 알지 못하는 A는 해커의 공개키가 B의 공개키라고 굳게 믿고 추후 B와 보안통신을 할 때 해커의 공개키로 암호화해 전달한다
    4. 이를 가로챈 해커는 자신의 개인키로 암호화 된 데이터에 접근한다. 아무런 문제없이 자신의 개인키로 복호화한 후 데이터를 확인하고 B의 공개키를 가지고 있으니 B의 공개키로 데이터를 암호화해 B에게 전달한다
    5. 수신자 B는 자신의 개인키로 암호문을 복호화한 후 수신을 완료한다

    이를 통해 발생하는 문제는 A가 데이터를 보낼 때 B의 공개키를 믿을 수 없게 된다는 것에 있다. 이러한 문제점을 해결하기 위해 제 3자의 공인된 인증기관(CA)에 자신의 공개키를 등록하고 이 공개키가 수납된 공인인증서를 발급 받아, 이 키를 필요로 하는 사람에게 배포하는 공인인증서 방법이 생겼다.


5. SSL/TLS 란?

SSL/TLS는 프로토콜로 PKI가 제공하는 공개 키 인프라와 디지털 인증서를 사용해서 Browser와 server 간 통신. 즉 Website 트랜잭션에 보안 및 무결성을 제공한다. 먼저 SSL은 Secure Socket Layer로 Browser와 Server가 서로 통신할 때 보안 및 무결성을 제공하는 프로토콜이다. TLS는 Transport Layer Security로 SSL과 마찬가지로 Browser와 Server가 서로 통신할 때 보안 및 무결성을 제공하는 프로토콜이다. 즉 SSL과 TLS는 동일한 목적을 수행하는 프로토콜이지만 차이점이라면 TLS 프로토콜은 SSL 프로토콜의 업데이트된 상위 버전이라는 것이다. SSL이 표준화 되면서 이름이 TLS로 변경되었고 TLS 1.0은 SSL 3.0을 계승한다. 또한 추가로 지원하는 알고리즘들이 존재한다.

자세한 과정을 살펴본다. 이 과정을 반드시 이해해야 한다.

  • TLS 통신과정 (Handshake과정)
    TLS 통신과정을 먼저 살펴본 후 동작과정을 살펴본다. 브라우저에 https://사이트주소 입력하여 접속한 이후의 과정이라고 보면 된다.

    1. 클라이언트 -> 서버
      • 클라이언트는 랜덤데이터를 만들어 서버에 보낸다.
      • 클라이언트에서 사용 가능한 암호화방식들을 서버에 보낸다.
    2. 서버 -> 클라이언트
      • 서버 또한 랜덤데이터를 만들어 클라이언트에 보낸다.
      • 클라이언트가 보낸 암호화방식들 중에 사용할 방식을 선정하여 클라이언트에 보낸다.
      • SSL 인증서도 같이 보낸다. (SSL 인증서에는 사이트의 Public Key, CA, 도메인 정보등이 존재)

  • TLS 동작과정
    pki001

pki002

pki003

  1. 사이트에서 Private Key, Public Key를 생성한다.
  2. 사이트는 신뢰할 수 있는 기관 CA에게 사이트의 Public Key와 사이트의 정보를 전달한다.
  3. 신뢰할 수 있는 기관 CA는 사이트의 Public Key를 Hash 함수를 통해 Hash 값을 생성한다.
  4. CA는 기관의 Private Key를 사용하여 공개키 알고리즘을 통해 Hash 값을 암호화 한다. (기관의 Private Key로 암호화 했기 때문에 전자서명)
  5. 최종적으로 인증서를 생성하며 인증서 내용에는 아래의 내용들이 포함된다.
    • 발행자: 신뢰할 수 있는 기관 CA
    • 공개키의 주인: 사이트 (사이트 정보도 포함)
    • 공개키: 사이트의 Public Key
    • 서명: 4번 단계에서 생성한 기관의 전자서명 값
  6. 생성한 인증서를 사이트에 전달한다.
  7. 사이트는 사이트의 Private Key와 CA로 부터 전달받은 인증서를 가지고 있는다.
  8. 사이트의 인증서를 브라우저에게 전달
  9. 브라우저는 사이트의 인증서를 저장하고 Public Key를 확인하기 위해 인증서 내용을 확인한다. 인증서에는 아래와 같은 내용이 포함되어 있다.
    • 발행자: 신뢰할 수 있는 기관 CA
    • 공개키의 주인: 사이트 (사이트 정보도 포함)
    • 공개키: 사이트의 Public Key
    • 서명: 전자서명
  10. Public Key를 확인했지만 해당 키가 정말 사이트의 Public Key인지 확인하기 위해 전자서명 값을 확인
  11. CA의 Public Key로 전자서명을 복호화하여 Hash 값을 확인
  12. 사이트의 Public Key를 Hash 함수를 통해 Hash 값 생성 한 후, 복호화된 Hash 값과 비교
  13. 값 비교가 일치한다면 해당 Public Key는 사이트의 Public Key임을 확인
  14. 브라우저는 대칭키 암호화에 사용할 임시 대칭키를 생성
  15. 임시 대칭키를 사이트의 Public Key로 암호화 하여 사이트에 전달한다.
  16. 사이트는 암호화 된 임시 대칭키를 Private Key로 복호화 하여 임시 대칭키를 확보 한다.
  17. 양쪽은 대칭키를 통해 암호화된 패킷을 주고 받을 수 있다.




  • References
    [1] https://retro-blue.tistory.com/43
    [2] https://ikcoo.tistory.com/359
    [3] https://www.lesstif.com/software-architect/pem-cer-der-crt-csr-113345004.html
    —

Tag: [ pki  ]