오래 못 할 짓 하지 않기

[ 컴퓨터 보안 ] 17. Cryptography - Public Key Infra : Digital Signature/ Key Distribution / Certificate Revocation 본문

3학년 2학기/컴퓨터 보안(Computer Security)

[ 컴퓨터 보안 ] 17. Cryptography - Public Key Infra : Digital Signature/ Key Distribution / Certificate Revocation

쫑알bot 2024. 11. 15. 15:40
728x90

Diffie - Hellman 방식에서의 취약점도 있다.

 

Eve가 모든 Packet들을 Capture할 수 있는 상황에서

 

1. Alice가 Bob에게 연결하려고 할 때, 그 사이에서 넘어오는 R1값을 받는다.

2. Eve가 R1값을 가지고 계산한 결과를 Alice에게 응답으로 보내고 K1을 만든다.

   ( Alice는 Bob에게 주고, Bob으로부터 받았다고 인식함 )

 

   2-1) 그리고 Eve는 Bob에게 그 R1값을 요청으로 보낸다.

 

3. Alice) R2를 가지고 K1값을 만든다. 

   3-1) Bob은 Eve에게 받은 R2값을 기반으로 R3를 만들어 보낸다.

 

4. Eve는 R3값을 가지고 다시 K2를 만든다. 

 

그럼 Eve는 Alice에게 Bob인 척을 할 수 있고, Bob에게는 Alice인 척 할 수 있다.

K1, K2 가 다 있어서 가능

 


이거 방어하는 방법은 Digital Signature를 사용하는 것이다.

계산한 R값을 응답해줄 때마다 본인의 Signature를 적어서 "이거 Bob이 보내는 거임 " 이라고 알려준다.

Eve가 Signature까지 따라할 수는 없기 때문에 이는 유효하다.

 

 

 


Public Key Distribution

Asymmetric Key 방식에서는

1. 모두에게 Public Key에 대한 Access 가 있다.

2. Public Key는 Public에서 (외부에서) Available 하다.

 

그럼 이걸 어떻게 나눠주냐?

 

📌 Certificate Authority (CA)

: CA에서 Public Key를 갖고 있는다.

 

[ 역할 ]

1. 들어온 Public Key에 대한 Certificate를 발행,갱신,폐기를 해준다.

2. [ Public Key - 유저 ] 에 대한 정보를 저장,업데이트도 해줌

3. 다른 프로토콜에게 서비스 제공

4. 접근 권한 Control

 

 

* CA가 털리는 상황을 대비하여, Certificate를 CA의 Private Key로 sign해둔다.

 

 

이러한 구조를 Public Key Infrastructure (PKI)라고 한다.

 


Digital Certificate

Digital version of PASSPORT 라고 보면 된다.

[ User - Public Key ] 를 세트로 보관한다.

 

이런 Digial Certificate는 

" 이 유저는 해당 Public Key에 대한 주인이고, 이에 문제가 없음을 보증함. " 이라는 뜻

여기에 추가적인 정보로는 

- Subject name (user)

- Public Key

- Validity 

..등등이 있다.

 

 


 Certificate Authority (CA) 작동

- User는 [ 본인의 Private Key ] 와 [ 다른 유저들의 Public key ] 를 기억하고 있어야 한다.

- 모든 유저는 CA에 접근하기 위해 CA의 Public Key를 복제하여 가지고 있다.

- CA는 A의 Digital certificate 란에 CA의 Private Key로 Sign하여 A에게 준다.

 

[ CA가 Sign하는 방법 ]

1. Certificate 칸 빼고 Message Digest를 한다.

2. Message digest + Certificate 칸은 CA의 Private Key로 Digital Signature

 

 

[ 내가 Verify하는 방법 ]

1. CA의 Public Key로 Signature을 De-Signing

2. De-Signing한 건 Certificate 빼고 다 digest한 값임.

Message를 Digest한 값 : De signing한 값 비교해보기

 

 

Q. CA한테 Public Key의 Certificate를 어떻게 받냐?

   > CA가 준 Certificate를 받으면 그 안에 Public Key가 들어있다.

 

F Q. CA한테는 누가 Sign해줌?

   > 계층적으로 Sign을 해주고, 마지막 root는 본인이 스스로 Sign을 한다.

 

 

📌 CA Hierarchy

: 계층적으로 CA 구조가 있고, 위에서 아래로 Certificate를 해주는 방식이다.

 

 

 

 

근데 아래 애들은 위에가 있는데, root CA는 누가 Certificate해줌??

 

Self-certification : root CA는 본인에게 스스로 할 수 있다.

3가지 방법이 있다.

 

1. Root CA 는 자동으로 누가 Certificate 안 해줘도 Trusted CA로 인식

2. Software가 Certificate된 root CA라고 Pre Programmed 해두기 ( 그냥 미리 등록해두는 거 )

3. 본인이 본인한테 Sign   

 

 

이런 것도 가능

 

 

 


 PKI Components

구조는 다음과 같다.

 

📌 Registeration Authority ( RA )

:  User와 CA 사이에서 조정하는 역할을 하는 Entity

 

[ 주요 업무 ] : CA의 업무를 조금 나눠 갖는다.

- User의 Registeration 정보를 확인하고 승인한다.

- User 대신 Key를 생성한다.

- Key Backup 및 복구 요청

- Certification 폐기 요청 승인

 

* 얘는 Certificate를 다룰 수 없음. 그냥 요청 전달하는 역할

* RA가 존재할 때, CA를 Isolated Entity로 둘 수 있기에, 보안적으로 안전하다.

 

📌 Key Recovery Server

: Key를 분실했을 때 복구해주는 역할을 한다.

 

유저가 분실했다면

1. CA는 해당 유저의 Certificate를 폐기한다.

2. 다시 [ 새로운 Public Key - User ] 를 만든다. 

3. 그에 맞는 Certificate 를 생성해준다.

 

 

Key 는 유저가 개인 Key를 생하는 시점에

CA가 백업해둔다.

 

* 키 복구 서버를 활용하면, 키 분실 상황에서도 재발급 과정을 빠르게 처리할 수 있어 사용자와 CA의 부담을 줄일 수 있다.

 

 

📌 Certificte Directory

Certificatie (인증서) 어디에 저장할거임?

 

> 1. User Local Machine 

 

> 2. CA는 Certificate Directory를 사용한다.

   = 중앙 디렉토리에 통합 저장한다.


 

Certificate Revocation

 

📌이유

 - Private key가 문제가 있거나 의심될 때

 - CA 가 Certificate를 만들면서 실수했을 때

 

 

 

📌종류

우리는 Key를 사용하기 전에 Certificate의 Validity를 확인한다.

 

- Offline

- Online

OFFLINE

-  Certification Revocation List (CRL) = Invalid한 Certificates들을 모아둔 파일

 

    1) 주기적으로 CA가 확인한다.

    2) CRL에는 Invalid(=Bad) 한 Certificates가 있지, 기간이 만료된 건 여기에 없다.

    3) Revocation Agency (RA) 가 관리한다.

        (Registeration Authority도 RA니까 구분하기)

 


ONLINE

- Online Certificate Status Protocol

  

    1) Client는 Server에게 Certificate 상태에 대한 정보를 요구하는 OSCP Request를 보낸다.

    2) 그럼 서버는 각 상태를 확인하여 즉각적으로 Certificates를 제공한다.

       

1. Client OSCP Request to Server

2. OCSP Responder(in server) 가 X.500 Dir에서 인증서 찾음

3. OCSP 가 유저에게 찾은 걸 Response

 

- CA가 이걸 같이 담당할 수 있는데, 같이 하기엔 다른 걸 하는 게 많아서 부하가 많아진다.

- OCSP에 Request하면서 계속 주고받는 게 약간 트래픽 낭비가 있다고 함

    > 미리 인증서를 받아두고 그걸 계속 사용할 수 있게 Cache에 넣어둔다. = OCSP Stapling

 

 

(출처)

한동대학교 컴퓨터 보안