대칭키 분배 방법 4가지

• 키분배(교환) : 암호 통신을 위해 통신 당사자들이 키를 확보하는 과정

• 대칭 키 분배의 문제 : 기밀성 + 인증이 필요함
  => MITM attack의 경우 인증이 없어서 발생하는 취약점임

• 키 교환 방법 4가지
  1. 키를 생성 후, 직접 전달
  2. 믿을 수 있는 제 3자가 직접 전달(TTP, Trusted 3rd-Party)
  3. 공유키로 암호화하여 상대방에게 전송
  4. 제 3자와 암호화된 연결(Secure channel)이 확립되어 있다면, 제 3자가 암호화된 링크를 통해서 전달(KDC, Key Distribution Center)
  

KDC 키 분배 절차

1. A가 B와 통신을 원하면 연결 요청 패킷을 KDC에 전송한다.

 => A와 KDC 사이에는 공유키가 존재하고 이를 이용하여 암호화 통신
2. KDC가 연결 요청 후, KDC는 일회용 세션키 K 생성

 => K를 공유키로 암호화하여 A에게 전송(B도 동일하게)
3. 이후, A와 B는 K로 암호화하여 통신

Kerberos

• MIT에서 개발한 대표적인 KDC 시스템
  버전4,5가 있지만, 버전4를 기준으로 설명하겠다.

Servers

Kerberos protocol에는 3가지 서버가 존재한다.

• AS(Authentication Server)
• TGS(Ticket-Granting Server)
• real server(data)

AS (Authentication Server)

AS(인증 서버)는 사용자를 검증(Verify)하고, 사용자와 TGS간의 세션키를 발행한다. 또한, TGS를 위한 티켓을 사용자에게 전달해준다.

TGS(티켓 발행 서버)는 data 서버(다른 유저가 존재)를 위한 티켓을 발행한다. 또한, 두 유저(통신을 위한)간에 사용될 세션키를 생성한다.

Real server(실제 서버)는 유저에게 서비스를 제공한다.

Kerberos는 인증(AS)과 실제 데이터를 주고받는 서버(Data server)를 분리했다는 것이 큰 특징이다.
Alice가 딱 한 번만 AS와 인증하면 실제 서버와 통신하기 위한 키를 얻기 위해 TGS와 여러번 접근하여 사용할 수 있다.

Kerberos has separated user verification from the issuing of tickets. In this way, though Alice verifies her ID just once with the AS, she can contact the TGS multiple times to obtain tickets for different real servers.

Kerberos는 왜 쓸까?

• 이전의 KDC 시스템에 비해 인증(Authentication) 단계가 추가되어 Replay-attack에 강하다.
• 세션키와 티켓의 암호화를 통해 높은 수준의 보안 강도를 유지할 수 있다.
  (다양한 암호 알고리즘을 통해 안전성 제공)
• 한 번 인증이 되면 여러번 서비스를 제공받을 수 있다.
  => SSO(Single Sign-On)기능을 사용하게 한다. 즉, 사용자는 AS와 1번 인증하기만 하면 실제 서버와 통신하기 위한 키를 얻기 위해 여러번 로그인할 필요 없게 한다.

Kerberos example

공개키 분배

• 공개키 분배의 문제
  이 공개키가 그 사람의(공격자의 것이 아닌)것이 맞는가?
  만약 공개키가 공격자의 것이라면, 해당 공격자는 자신의 개인키로 메시지를 복호화할 수 있다.

• 안전한 (소유자가 확인된) 공개키 전달
  신뢰 있는 제 3자(TTP, Trusted Third-Party)를 사용하자!!

공개키 인증서 활용

유저의 ID정보와 공개키, CA(Certificate Authority, 인증기관)의 정보가 들어있는 인증서를 CA가 서명한다.

X.509 인증서

표준화된 공개키 인증서 규격 표준이다.

각 인증서 버전에 따라 담고 있는 내용의 정보가 다름을 알 수 있다.

인증서는 여러 이유로 Revocation(취소, 폐지)되는데, 그에 대한 인증서 취소 목록 표준은 위 그림과 같다.

CRL (Certificate Revocation List, 인증서 취소 목록)는

• 각 CA는 취소했지만, 유효기간이 아직 끝나지 않은 인증서 목록을 보관
• 취소된 인증서들은 사용자에게 발행한 것과 다른 CA들에게 발행한 것 모두를 포함
• 취소 목록을 디렉토리에 공개

어떤 사이트에 접속할 때, 브라우저는 해당 인증서(TLS, HTTPS를 위한)가 CRL에 포함되어있는지 여부를 확인함.
만약, 해당 인증서가 CRL에 포함되어 있다면, 사이트를 신뢰하지 않음으로 간주.

X.509 계층 구조

X << Y >> : X 노드가 Y 노드의 인증서를 신뢰한다는 것을 나타낸다.
즉, Y의 인증서가 X의 신뢰 체인에 포함되어 있다는 뜻이다.
이 경우, 상위 기관은 Y.

이 표현은 신뢰 체인에서 X가 Y에 의해 서명되거나, X의 신뢰 관계가 Y를 통해 이어진다는 것을 의미한다. X는 Y의 인증서를 통해 검증될 수 있으며, 이는 인증서 체인에서 상위 CA로부터 신뢰를 전달받는 과정을 나타낸다.

공개키 기반 구조

PKI(Public-Key Infrastructure, 공개키 기반 구조)
RFC 2828(Internet Security Glossary)에서 정의

https://datatracker.ietf.org/doc/rfc2828/

디지털 인증서를 생성, 관리, 저장, 분배, 취소하는데 필요한 인프라(하드웨어, 소프트웨어) + 사람, 정책 및 절차를 통합하여 의미함.

PKIX

PKIX(Public-Key Infrastructure X.509)는 X.509 기반의 공인 인증서를 사용하기 위한 아키텍처와 프로토콜을 지정하는 IETF 작업 그룹의 이름이다.

PKIX의 목표는 X.509 공개 키 인증서를 다양한 인터넷 애플리케이션에서 사용하고, 다른 구현 간의 상호 운용성을 촉진하는 것이다. PKIX는 인증서 프로필, 운영 및 관리 프로토콜, 인증서 정책 및 CPS에 관한 정보를 포함하는 표준을 제공한다.

PKIX 관리 프로토콜

CMP(Certificate Management Protocol, 인증서 관리 프로토콜)
CMS(Cryptographic Message Syntax, 암호 메시지 구문)

• CMS는 디지털 서명, 해시, 암호화를 사용하여 임의의 메시지를 캡슐화하는 방식이다. PKCS#7에서 파생되었으며, ASN.1로 지정되고 BER 인코딩을 사용한다. 이 문법은 메시지와 함께 다양한 속성을 서명할 수 있으며, 디지털 인증서를 기반으로 한 다양한 키 관리 아키텍처를 지원한다.

Task#1

rootCA, Intermediate CA, user CA의 인증서를 만들고 root CA를 서버에 Install하고 인증서 체인을 검증해라.

Background

openssl은 방대한 암호, 인증서 관련 도구이다.
간단하게 X.509 인증서를 생성 할 수 있다.

$ openssl genrsa -out myCA.key 2048

• rsa를 이용하여 2048길이의 키를 생성한다.

$ openssl req -x509 -new -nodes -key myCA.key -days 365 -out myCA.pem

• 개인키를 이용하여 새로운 인증서를 만든다.(자체 서명)

$ openssl req -new -key myPri.key -out myCert.csr

• 개인키를 이용하여 인증요청서(CSR)을 생성한다.

$ openssl x509 -req -in myCert.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial -out myCert.crt -days 365

CSR을 이용하여 인증서를 발급한다.

req 커맨드 : PKCS#10 인증서 요청과 인증서 생성 커맨드
x509 커맨드 : 인증서를 보거나 서명하는 다목적 커맨드

-x509 : 해당 옵션은 인증서를 생성하는 옵션이다. -CA 옵션을 사용하면 생략할 수 있다.

-new : 새로운 인증서 요청을 생성한다. 프롬프트에 인증서 필드에 대한 값을 유저에게 보여준다.

-nodes : deprecated in 3.0v

-key : 서명을 위한 키를 지정하는 옵션이다.

-days : 유효기간을 지정한다.