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

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

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

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

  • 공개키 암호 시스템

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

  • PKI (Public Key Infrastructure)와 인증서 체인(Certificate Chain)을 사용한 서명 프로세스

    • 개발자에 의해 키 쌍이 생성된다.
    • 서명(Signature) 절차를 밟고 인증서(Certifcate)를 생성한다.
    • CA는 개발자의 공개키를 CA 비밀키로 서명하여 신원 보증
      • 개발자의 공개키가 CA에서 신원이 확인된 개발자로부터 생성된 것임을 명시하기 위함
    • 운영체제/브라우저는 인증서 체인(Certificate Chain) 검증
      • Leaf(앱/웹) 인증서 -> 상위 인증서 -> Root CA 인증서 순으로 검증이 이뤄지며 다음의 절차를 밟는다.
        • 개발자의 서명을 검증(복호화)하여 해시값 추출 후, 원본 데이터의 실제 해시 결과와 비교 (=무결성 검사)
        • 인증서가 상위 인증서의 비밀키로 서명되어 있는지 확인
        • 상위 인증서가 루트 CA의 비밀키로 서명되어 있는지 확인
      • 참고로 운영체제/브라우저에는 신뢰할 수 있는 루트 CA의 공개키가 내장되어 있다.
        • 내장된 CA 공개키로 개발자가 생성한 인증서로부터 공개키를 추출할 수 있다.

  • PKI 활용 예시

    • 웹 to 서버

      • 서버는 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 가 제공하는 인증서를 사용할 시, 브라우저의 주소창이 신뢰 가능 여부를 표시

          1.png

          2.png

      • 브라우저는 해당 공개키로 인증서를 복호화하여 획득한 서버의 공개키를 클라이언트에 제공
      • 클라이언트는 서버의 공개키가 신뢰할 수 있는 업체에 의해 제공되었음을 확인
      • 클라이언트는 송신하고자 하는 데이터(대칭키 등)를 서버의 공개키로 암호화하여 요청 수행

    • 안드로이드 to 프록시 to 서버

    • 안드로이드 앱 서명