[ETC] PKI, SSL/TLS, 인증서

 

1. PKI 구성요소

 

인증기관(CA : Certication Authority)

인증정책 수립 및 인증서 폐기목록 관리

 

등록기관(RA : Registration Authority)

사용자와 인증기관이 멀 경우 인증서 신청시 인증기관 대신에 신분과 소속을 확인한다.

 

인증서란

 : 사이트의 Public Key(공개키)와 사이트 정보(전자서명 등)을 인증기관의 Private Key(개인키)로 암호화한 파일에 불과하다.

 

>> SSL/TLS 인증서

 : SSL은 SSL인증서(=TLS인증서)가 있는 웹사이트만 실행할 수 있다. 인증서는 사람의 신분증과 유사하다고 볼 수 있다.

SSL인증서에는 공개 키가 포함된다. 이 공개키 덕분에 암호화가 가능하게 된다. 클라이언트의 요청은 공개 키를 이용해 서버에 암호화 하여 전달한다. 서버에도 공개되지 않는 개인 키가 있는데 이 개인 키를 이용해 암호화된 데이터를 복호화한다.

 

	대칭키	비대칭키
키 관계	암호화 키 = 복호화키	암호화 키 ≠ 복호화 키
암호화 키	비밀키	공개키
복호화 키	비밀키	개인키
비밀키 전송	필요	불필요
키 길이	짧다	길다
인증	곤란	용이
암복화 속도	빠르다	느리다
경제성	높다	낮다
전자서명	복잡	간단
주 용도	고용량 데이터 암호화(기밀성)	키 교환 및 분배, 인증, 부인방지
장점	- 암▪복호화 키 길이가 짧다 - 구현이 용이하고, 암▪복호화가 빠르다 - 암호화 강도 전환이 용이 - 암호화 기능이 우수 - 각종 암호 시스템의 기본으로 활용	- 사용자가 증가하더라도 관리해야 할 키의 개수가 상대적으로 적다 - Key 전달이나 교환에 적합하다 - 인증과 전자 서명에 이용 - 대칭키 보다 확장성이 좋다 - 여러가지 분야에서 응용이 가능 - 키 변화의 빈도가 적음
단점	- 키 교환 원리가 명시되지 않음  → 키 분배가 어렵다 - 관리할 암▪복호화 키가 많다   N명 → N(N-1)/2 - 확장성이 낮다 - 전자서명(디지털서명)이 불가능 - 부인방지 기능이 없다	- 키 길이가 길다 - 복잡한 수학적 연산을 이용함으로 암호화▪복호화 속도가 느리다 - 중간에 인증과정이 없으므로 중간자 공격에 취약하다 (전자서명,인증서 등으로 해결)
예	[Feistel] : SEED, DES [SPN] : ARIA, AES, IDEA 메시지 인증코드(MAC)	Diff-Hellman, RSA, ECC, DAS [Block chain] [TPM]

 

2. SSL인증서 유효성 검증

 

CRL (Certificate Revocation Lists)이란 인증서 해지 목록이며, 해지되었거나 더 이상 유효하지 않은 인증서의 목록을 의미합니다. 인증기관은 SSL인증서를 해지 한 후 인증서의 정보를 CRL목록에 등록합니다.

 

SSL인증서의 유효성을 확인하기 위해 클라이언트는 URL에 접속하여 인증기관이 등록한 CRL목록을 다운로드한 후 인증서의 일련번호(serial number)을 통해 유효성을 확인합니다.

 

 

SSL(Secure Scokets Layer)

은 암호화 기반 인터넷 보안 프로토콜이다. 전달되는 모든 데이터를 암호화하고 특정한 유형의 사이버 공격도 차단한다. SSL은 TLS(Transport Layer Security) 암호화의 전신이기도 한다.

 

SSl/TLS 를 사용하는 웹사이트 URL은 HTTP 대신 HTTP가 사용된다.

 

 

 

 

 

SSL은 1996년 SSL 3.0 이후 업데이트되지 않았으며, 앞으로 사라지게 될 것으로 여기지고 있다. 또한 알려진 취약성이 여러가지 있으며 보안 전문가들은 SSL 사용 중단을 권장한다고 한다. 그 대안으로는 앞에서 언급한 TLS가 있다.

TLS는 최신 암호화 프로토콜로, SSL 암호화로 혼용해서 부르는 경우도 많다. 실제로 현재 SSL을 인증한 업체 및 제공하는 업체는 사실상 TLS 암호화를 제공하고 있는것이다.

 

TLS

TLS 는 SSL의 업데이트 버전으로 SSL의 최종버전인 3.0과 TLS의 최초버전의 차이는 크지않으며, 이름이 바뀐것은 SSL을 개발한 Netscape가 업데이트에 참여하지 않게 되어 소유권 변경을 위해서였다고 한다.

결과적으로 TLS는 SSL의 업데이트 버전이며 명칭만 다르다고 볼 수 있다.

 

SSL/TLS 의 작동 방식

SSL은 개인정보 보호를 제공하기 위해, 웹에서 전송되는 데이터를 암호화 한다. 따라서, 데이터를 가로채려해도 거의 복호화가 불가능하다.

SSL은 클라이언트와 서버간에 핸드셰이크를 통해 인증이 이루어진다. 또한 데이터 무결성을 위해 데이터에 디지털 서명을 하여 데이터가 의도적으로 도착하기 전에 조작된 여부를 확인한다.

 

 

SSL/TLS 핸드셰이크

핸드셰이크는 클라이언트와 서버간의 메세지 교환이며,  HTTPS 웹에 처음 커넥션할 때 진행된다. 

핸드셰이크의 단계는 클라이언트와 서버에서 지원하는 암호화 알고리즘, 키 교환 알고리즘에 따라 달라진다.

일반적으로는 RSA 키 교환 알고리즘이 사용된다.

 

> TCP핸드쉐이크 이후 진행

 

1. ClientHello : 클라이언트가 서버에 연결을 시도하며 전송하는 패킷이다. 

 

2. ServerHello : 서버는 클라이언트가 보내 온 ClientHello 패킷을 받아 Cipher Suite 중 하나를 선택한 다음 클라이언트에게 이를 알린다.

 

3. Certificate : Server가 자신의 SSL 인증서를 클라이언트에게 전달한다.

 

4.Server Key Exchange / ServerHello Done

 : 서버의 공개 키가 SSL 인증서 내부에 없는 경우, 서버가 직접 전달한다는 뜻이다. 공개 키가 SSL 인증서 내부에 있을 경우 Server Key Exchange는 생략된다. 인증서 내부에 서버의 공개 키가 있다면, 클라이언트가 CA의 공개 키를 통해 인증서를 복호화 한 후 서버의 공개 키를 확보할 수 있다. 그리고 서버가 행동을 마쳤음을 전달한다.

 

5.Client Key Exchange : 

 : 클라이언트는 데이터 암호화에 사용할 대칭 키를 생성한 후 SSL 인증서 내부에서 추출한 서버의 공개 키를 이용해 암호화한 후 서버에게 전달한다. 여기서 전달된 대칭 키가 SSL Handshake의 목적이자 가장 중요한 수단인 데이터를 실제로 암호화할 대칭 키다. 이제 키를 통해 클라이언트와 서버가 실제로 교환하고자 하는 데이터를 암호화한다.

 

6. ChangeCipherSpec / Finished

: ChangeCipherSpec 패킷은 클라이언트와 서버 모두가 서로에게 보내는 패킷으로, 교환할 정보를 모두 교환한 뒤 통신할 준비가 다 되었음을 알리는 패킷이다. 그리고 Finished 패킷을 보내어 SSL Handshake를 종료하게 된다.

 

.

 

 

 

 

출처

https://m.blog.naver.com/chodahi/221406393028

https://cert.crosscert.com/ssl%EC%9D%B8%EC%A6%9D%EC%84%9C-%EC%9C%A0%ED%9A%A8%EC%84%B1-%EA%B2%80%EC%A6%9D-ocspcrl/

https://kanoos-stu.tistory.com/46