대칭키 암호화 vs 비대칭키 암호화

• 대칭키 암호화
  • 암호화, 복호화 시에 사용하는 키가 동일
• 비대칭키 암호화
  • 암호화 전용, 복호화 전용 키가 별도로 존재한다.
  • 공개키 암호 시스템에서 사용되는 개념이다.
    • (하단의 공개키 암호 시스템 항목에서 자세히 서술할 것이니 참고)

비대칭키, 대칭키를 사용한 기본적인 통신 매커니즘

• 먼저 공개키 암호 시스템 방식으로 대칭키를 주고 받는다.
  • 대칭키 암호화에 비해 상대적으로 보안이 엄격한 방식으로 통신 채널을 개설하기 위함이다.
• 이후 데이터를 주고 받는 과정에서 대칭키 암호화 방식을 사용한다.
  • 공개키 암호화 방식은 많은 컴퓨팅 파워를 요구하기 때문이다.
• 키 교환 프로세스
  • 비밀키 소유자 A가 공개키를 공개
  • B는 A가 공개한 공개키로 자신의 대칭키를 암호화하여 전송
    • 이 암호화된 값은 비밀키를 가지고 있는 A만이 복호화할 수 있다.
  • A는 암호화된 대칭키를 수신한 후, 자신의 비밀키로 복호화 -> 즉 B의 대칭키를 확인
    • 이 단계에서 대칭키를 양쪽에서 비밀리에 주고받는데 성공
  • 이후 A와 B 단 둘이 알고 있는 대칭키를 통해서 빠른 암호화 통신 진행
• 예시
  • 세션 시작될 시, session key 교환한 후 해당 키로 암호화한 데이터를 상대에게 전송
  • 세션 종료 시, SSL 통신이 끝났음을 서로에게 알린 후 대칭키인 session key 폐기

공개키 암호 시스템

• 사용 키
  • 공개키 -> 공개적으로 배포되는 키
  • 비밀키(개인키) -> 공개하지 않는 키
• 목적에 따라 암호화 과정에서 사용하는 키가 다르다.
  • 비밀 데이터 전송 시
    • 공개키로 암호화
    • 개인키로 복호화
  • 전자 서명 및 서명 검증 시
    • 개인키로 암호화 (=전자 서명)
      • 개인키로 암호화 하는 이유
        • 개인키를 소유한 자신만이 암호화를 수행할 수 있음을 보여주기 위함
        • 개인키로 자신의 신원을 표기하는 이러한 행위를 전자서명(=sign)이라고 한다.
      • 암호화 대상
        • 서명하고자 하는 데이터의 해시값 (알고리즘은 대개 SHA256를 적용)
        • 데이터를 256 비트 크기로 축소하는 것 외에 기밀성(단방향), 무결성(일치 여부)을 보장하기 위해 사용
      • 송신자는 다음의 두 가지를 송신한다.
        • 데이터 원본
        • 전자 서명 (데이터 원본에 해시 적용 한 후, 이를 개인키로 암호화한 결과물)
    • 공개키로 복호화 (= 검증)
      • 수신자는 데이터 원본에 해시 함수 적용하여 해시값 생성
      • 수신자는 전자 서명을 송신자의 공개키로 복호화하여 해시값 추출
      • 두 해시값 비교
      • 해당 서명이 서명자의 개인키로 서명(암호화)되었음을 증명
      • 신원 확인 완료

공개키 암호 시스템을 활용한 통신 매커니즘 예시

• 웹 <-> 서버

  • 서버는 HTTPS 적용 시 필요한 인증서를 발급받기로 결정

  • 먼저 서버와 클라이언트 간 통신에 필요한 공개키와 개인키(비밀키) 생성

  • 서버는 신뢰할 수 있는 (공개키 저장소) 역할을 하는 CA 기업을 선택

    • CA(certificate authority) 기업: SSL을 통해서 암호화된 통신을 할 수 있도록 인증서를 제공해주는 곳
    • 신뢰도가 높은, 공인된 기업들이 CA 기업으로서의 자격을 가질 수 있다.

  • 서버는 CA 기업에 자신의 공개키를 관리하도록 한 후 일정 금액 지불

  • CA 기업은 CA 기업의 이름, 서버의 공개키 등의 정보를 담은 인증서 생성

  • CA 기업은 해당 인증서를 CA 기업의 개인키로 암호화(=전자 서명)한 후 서버에게 제공

    • 참고로 CA 기업은 CA 의 기업만의 공개키와 개인키가 따로 있음

  • 서버는 CA에 의해 암호화(전자서명 = 공신력이 입증)된 인증서(SSL 인증서)를 갖게 됨

    • SSL 인증서: 클라이언트와 서버간의 통신을 제 3자(CA)가 보증해주는 전자화된 문서

  • 이제 서버는 서버의 공개키로 암호화된 HTTPS 요청이 아닌 다른 요청이 올 경우, 해당 인증서를 클라이언트에게 전달

    • 예를 들어 클라이언트가 서버에게 index.html 파일을 달라고 요청했다고 가정
    • 클라이언트는 CA 기업이 서버의 정보를 CA기업의 개인키로 암호화한 인증서를 받게 됨.

  • 클라이언트의 브라우저는 해당 인증서를 CA 공개키로 복호화(하여 전자 서명한 인증서에 대한 신뢰성 검증)

    • (세계적으로 신뢰할 수 있는 CA 기업의 공개키는 브라우저가 이미 알고 있다.)

    • 공인된 CA 가 제공하는 인증서를 사용할 시, 브라우저의 주소창이 신뢰 가능 여부를 표시

      

      

  • 브라우저는 해당 공개키로 인증서를 복호화하여 획득한 서버의 공개키를 클라이언트에 제공

  • 클라이언트는 서버의 공개키가 신뢰할 수 있는 업체에 의해 제공되었음을 확인

  • 클라이언트는 송신하고자 하는 데이터(대칭키 등)를 서버의 공개키로 암호화하여 요청 수행

    • 데이터는 공개키로 암호화해야 함을 잊지 말자
• 안드로이드 <-> 프록시 <-> 서버
  • 기본적으로 안드로이드 앱은 HTTPS 통신 수행 시, 안드로이드 시스템에서 제공하는 CA 목록을 참조한다.
  • 그러나 프록시 서버(혹은 내부 서버)의 경우, 인증서가 CA에 등록되어 있지 않아 서명 검증이 불가한 문제가 발생한다.
    • 웹이 아닌 앱이기 때문에 브라우저를 통해 인증서를 다운받을 수도 없다.
    • 프록시 서버나 내부 서버는 자체 서명된 인증서를 사용하는 경우가 많다.
  • 이 경우, 안드로이드 디바이스에 프록시 서버의 디지털 인증서(cert, pem 등)를 직접 제공해야 한다.
    • 앱에서 mitm 프록시 서버에 접근하기 위해, 디바이스에 mitmproxy-ca.pem 파일을 넣어주는 것도 이 때문이다.
    • 참고로 해당 인증서 내부에는 프록시 서버(mitm proxy 프로그램)의 공개키가 저장되어 있다.
  • 클라이언트는 인증서에서 추출한 프록시 서버의 공개키로 데이터를 암호화한 후, 프록시 서버에 요청을 보낸다.
• 안드로이드 앱 서명
  • 키스토어 파일(jks)에는 다음의 두 가지가 포함되어 있다.
  • 개발자는 앱 업로드를 위한 서명을, 구글은 개발자의 신원을 검증한 후 앱을 배포하고 관리하기 위한 서명을 수행한다.
  • 디바이스는 앱 설치 시 앱의 출처가 구글 플레이가 맞는지 여부를 확인한다.

디지털 인증서를 가리키는 대표적인 확장자로 cert와 pem이 있다.