SSL/TLS

 

TLS 인증 과정은 클라이언트와 서버 간에 안전한 통신 채널을 설정하기 위한 단계입니다. TLS(Transport Layer Security)는 서버 인증과 선택적으로 클라이언트 인증을 통해 데이터의 기밀성, 무결성, 신뢰성을 보장합니다.

 

. TLS 인증 과정 요약

1. 클라이언트와 서버가 TLS 핸드셰이크를 시작합니다.
2. 서버 인증서를 통해 서버의 신뢰성을 검증합니다.
3. 선택적으로 클라이언트 인증서로 클라이언트를 인증합니다.
4. 세션 키를 생성 및 교환하여 암호화된 통신 채널을 설정합니다.
5. 이후 대칭키 암호화를 사용해 데이터를 안전하게 전송합니다

TLS 인증 과정 단계별 설명

2.1 핸드셰이크 시작

• 클라이언트가 서버에 TLS 연결 요청을 보냅니다.
• 클라이언트는 지원하는 TLS 버전과 암호화 알고리즘 목록(암호군, Cipher Suites)을 서버에 전송합니다.

2.2 서버 인증

1. 서버는 자신의 디지털 인증서를 클라이언트에게 전송:
   • 이 인증서에는 서버의 공개키와 신원 정보(도메인 이름, 조직 정보 등)가 포함되어 있습니다.
   • 인증서는 CA(Certificate Authority)에 의해 서명되어야 합니다.
2. 클라이언트는 서버 인증서를 검증: 
   • 인증서의 CA 서명을 확인하여, 인증서가 신뢰할 수 있는지 검증합니다.
   • 인증서의 유효기간과 대상 도메인(예: www.example.com)을 확인합니다.
3. 인증서의 내용물
   (1) 인증서의 소유자 이름, 
   (2) 인증서 소유자의 공개 키 (비밀 키는 소유자가 가지고 있다), 
   (3)인증서의 유효기간,
   (4) 고유한 UID
   (5) 인증서의 내용을 종합해 해시화한 값(digest) 을 CA의 비밀키로 암호화(서명)한 값 
   인증서라는 것은 하나의 파일임인증서 검증 시 해시 값 검증 과정
   1. CA의 서명 생성 과정:
      • 인증서를 발급할 때, CA는 인증서 내용을 해시 함수(SHA-256 등)를 사용해 해시 값을 생성합니다.
      • 이 해시 값을 CA의 개인키로 암호화하여 전자서명을 만듭니다.
      • 결과적으로, 인증서에는 CA의 전자서명이 포함됩니다.
   2. 클라이언트가 서버 인증서를 검증할 때:
      • 클라이언트는 CA의 공개키를 사용하여 서버 인증서에 포함된 CA의 전자서명을 복호화합니다.
      • 복호화된 값은 인증서 내용의 원래 해시 값이 됩니다.
      • 클라이언트는 인증서 내용을 해싱하여 새로운 해시 값을 계산합니다.
      • 두 해시 값을 비교하여 동일하면, 인증서가 변조되지 않았음을 확인합니다.

2.3 클라이언트 인증 (선택적)

• 서버가 클라이언트의 신원을 인증해야 할 경우, 클라이언트에 클라이언트 인증서를 요청합니다.
• 클라이언트는 자신의 디지털 인증서를 서버에 전송하고, 서버는 이를 검증합니다.

2.4 세션 키 생성 및 교환

1. 대칭키 설정:
   • 클라이언트와 서버는 **대칭키(세션 키)**를 생성합니다.
   • 대칭키 생성 방식:
     • RSA:
       • 클라이언트는 서버의 공개키로 대칭키를 암호화하여 전송.
       • 서버는 자신의 개인키로 복호화하여 대칭키를 얻음.
       •  
         • 클라이언트에서 생성됩니다.
           • 클라이언트는 대칭키를 생성한 후, 이 대칭키를 서버의 공개키로 암호화하여 서버에 전송합니다.
         작동 방식
         1. 클라이언트:
            • 대칭키를 생성.
            • 서버의 공개키를 사용하여 대칭키를 암호화.
            • 암호화된 대칭키를 서버에 전송.
         2. 서버:
            • 자신의 개인키를 사용하여 클라이언트로부터 받은 대칭키를 복호화.
            • 복호화한 대칭키를 사용하여 이후 통신에 사용.
         요약
         • 대칭키는 클라이언트에서 생성되고, 서버는 이를 복호화하여 사용합니다
     • ECDHE (Elliptic Curve Diffie-Hellman Ephemeral):
       • 클라이언트와 서버가 각각 키를 교환하여 대칭키를 계산.
2. 세션 키 공유:
   • 클라이언트와 서버는 대칭키를 안전하게 공유하고, 이후의 데이터는 대칭키로 암호화됩니다.

2.5 핸드셰이크 완료

• 클라이언트와 서버는 핸드셰이크 과정을 성공적으로 완료하면 암호화된 통신 채널을 설정합니다.
• 이후 데이터를 주고받으며 기밀성, 무결성, 인증을 보장합니다.

 

---

1. 기밀성 (Confidentiality)

• 데이터가 인가된 사용자만 접근할 수 있도록 보호하는 것입니다.

---

2. 무결성 (Integrity)

 

• 데이터가 전송되거나 저장되는 동안 변조되지 않았음을 보장하는 것입니다.

보장 방법:

1. 해시(Hash) 사용:
   • 데이터의 해시 값을 계산하여, 변경 여부를 확인.
   • 예: SHA-256.
2. 메시지 인증 코드(MAC):
   • 데이터를 전송할 때 MAC을 추가하여 변조 여부를 검증.
   • 예: HMAC.
3. 디지털 서명:
   • 데이터가 신뢰할 수 있는 주체에 의해 생성되었고 변조되지 않았음을 확인.
   • 예: RSA 서명.

예시:

• 파일 다운로드 시 제공되는 해시 값(SHA-256)을 비교하여 파일이 변조되지 않았음을 확인.

---

3. 신뢰성 (Authentication)

의미:

• 데이터를 전송하거나 요청하는 주체의 신원을 확인하는 것입니다.
• 데이터가 신뢰할 수 있는 발신자/수신자에 의해 생성되었고, 인증된 사용자가 접근했음을 보장합니다.

보장 방법:

1. 사용자 인증:
   • 사용자가 시스템에 로그인할 때 신원을 확인.
   • 예: 비밀번호, 생체 인증(지문, 얼굴 인식).
2. 디지털 인증서:
   • 인증서를 통해 데이터 발신자/수신자의 신원을 확인.(단방향 TLS에서는 서버의 신원만 확인함)
   • 예: TLS에서 서버 인증서.
3. 전자서명:
   • 데이터를 서명하여 발신자의 신뢰성을 증명.
   • 예: PDF 문서 서명.

예시:

• 클라이언트가 서버의 SSL 인증서를 검증하여 신뢰할 수 있는 웹사이트임을 확인.

 

 

---

1. TLS에서 무결성 보장의 핵심 원리 (핸드셰이크 후)

1 메시지 인증 코드 (MAC)

• TLS는 전송되는 데이터에 대해 **메시지 인증 코드(MAC)**를 계산하여 무결성을 보장합니다.
• MAC은 데이터와 세션 키를 기반으로 생성되며, 데이터가 전송 중 변경되었는지 확인할 수 있습니다.

동작 원리:

1. 데이터 송신 시:
   • 데이터와 세션 키를 기반으로 MAC을 생성.
   • 데이터를 암호화한 뒤, MAC을 함께 전송.
2. 데이터 수신 시:
   • 수신자는 데이터와 세션 키를 기반으로 MAC을 재계산.
   • 송신된 MAC과 수신자가 계산한 MAC을 비교.
   • 두 MAC이 일치하면 데이터가 변조되지 않았음을 확인.

2 AEAD(Authenticated Encryption with Associated Data)

• 최신 TLS(1.2 이후)에서는 AEAD 알고리즘(예: AES-GCM, ChaCha20-Poly1305)을 사용합니다.
• AEAD는 암호화와 무결성 검증을 동시에 수행합니다.
• 이는 기존의 "암호화 후 MAC" 방식보다 효율적이고 안전합니다.

동작 원리:

1. 데이터 암호화와 무결성 검증을 동시에 수행.
2. 수신자는 암호화를 해제하며 데이터의 무결성을 자동으로 검증.
3. 무결성이 보장되지 않은 데이터는 복호화되지 않고 버려짐.