대칭키 분배방법 4가지

• ex) 둘이 쓰는 사물함

1. A가 키를 생성(선택) 후 B에게 직접 (안전하게, Secure channel) 전달

2. 제3자가 키를 A와 B에게 직접 전달

• 믿을 수 있는 ( = MITM이 아님을 확인할 수 있는, 정직하게 행동하는 )
☞ TTP ( Trusted Third Party ) , honest broker..

3. A와 B의 공유키로 암호화하여 상대방에게 전송

4. A와 B가 제3자인 C와 암호화된 연결( Secure channel ) 이 확립되어 있다면, C가 암호화된 링크를 통해서 A와 B에게 키를 전달

• 키분배 센터: KDC
  

• 키교환 3을 위해서는 키교환1을 M^2 해야 함
• 키교환 4를 위해서는 키교환1을 M번 하면 됨

공개키(비대칭키) 분배방법

• ex) 우편함

• 공개키라 기밀성은 필요없음. 소유자 확인만 필요!

Direct 확인 : 소유자를 직접 확인하고 전달

• 대면 확인 후 공개키 교환
• 키를 직접 전달하는 대신 추후 인증할 수단을 전달할 수도 있음

공개키 인증서 (public-key certificate) : by TTP

• 공개키와 키 소유자의 사용자 ID로 구성
• 정부기관이나 금융기관 같은 사용자 모두가 신뢰하는 인증기관(CA: certificate authority)이 서명

공개키를 이용한 키교환

공개키 인증서 활용

1. 메시지를 준비한다
2. 일회용 세션키를 이용하는 대칭암호 기법으로 메시지를 암호화
   한다
3. 수신자의 공개키를 이용해서 그 세션키를 암호화한다

• 공개키 인증서 안에 들어 있는 공개키를 사용

4. 암호화된 세션키를 메시지에 첨부해서 수신자에게 보낸다
   

4. X.509 인증서

▶표준화된 공개키 인증서

• ITU-T 권고안 X.509는 디렉터리 서비스를 정의하는 권고안
X.500 시리즈의 한 부분
• 공개키 인증서 규격에 대한 표준

▶디렉터리

• 사용자 정보 데이터베이스를 관리하는 하나의 서버 또는 분
산 서버 집단
• 공개키 인증서의 공개 저장소로 이용

CRL 취소 인증서 목록

• 공격자가 개인 키를 가지고 있다면 민감한 정보를 해독할 수 있기 때문.
• 각 CA 는 취소했지만 유효기간이 아직 끝나지 않은 인증서 목
  록을 보관
• 취소된 인증서들은 사용자에게 발행한 것과 다른 CA 들에게 발
  행한 것 모두를 포함
• 취소 목록을 디렉토리에 공개

다음에 "SafeShop.com"을 방문할 때 인증서를 신뢰하기 전에 브라우저 또는 애플리케이션에서 CRL을 확인해봄 > 해당 CRL 목록에서 "SafeShop.com" 인증서를 찾으면 사이트를 신뢰하지 않으며 연결이 안전하지 않을 수 있음을 경고합니다.

블록체인에서의 공개키

• 블록체인은 인증서가 없어.
• pub key 공개키 가 곧 id

5. 공개키 기반구조

• PKI 에서 정의

• 디지털 인증서를 생성,관리, 저장하고 배분하며 취소하는데 필요한 인프라,정책

• 안전하고 편리하고 효율적인 공개키 획득을 위해

PKIX

• X.509 인증서 시스템이 인터넷에서 효과적으로 작동하도록 보장하는 프레임워크.

PKIX 구조적 모델, 구성요소

인증 기관(CA)

• 인증서를 발급하고 관리하는 신뢰할 수 있는 기관입니다.

인증서 해지 목록(CRL)

• 만료 날짜 전에 해지된 인증서가 포함된 CA에서 관리하는 목록입니다.

등록 기관(RA)

• CA가 인증서를 발급하기 전에 CA의 확인자 역할을 할 수 있는 선택적 엔터티입니다.

관리 기능

• 인증서 만들기
• 인증서 유효성 검사
• 인증서 해지

---

CA 인증서 만들기

• CA 의 self signed 인증서를 만든다.

인증서 검증

• 인증서 유효성 검사는 제시된 인증서가 진짜인지, 변조되지 않았는지, 신뢰할 수 있는 기관(일반적으로 인증 기관 또는 CA)에서 발급했는지 확인하기 위한 중요한 단계

특정 SSL 서버 인증서 체인을 확인

$ openssl s_client -connect www.google.com:443

내가 만든 인증서 체인 검증하기

openssl verify -show_chain -CAfile myCA.pem myCert.crt

중간 CA 가 포함시

$ openssl verify -show_chain -CAfile myCA.pem -untrusted intermediateCA.pem myCert.crt

과제 1

rootCA , 중간 CA, 사용자 인증서 만들기 (1점)
• CN=이니셜ROOT, 이니셜CA, 이니셜 (본인 이니셜 사용)
• 파일명도 상기이름.확장자
• 인증서 파일 3개 제출 ( pri key 파일 제외)

---

1. 루트 CA를 생성합니다:

루트 CA 개인 키를 생성합니다:

openssl genrsa -out rootCA.key 2048

루트 CA 인증서(자체 서명)를 생성합니다:

YOUR_INITIALS를 실제 이니셜로 바꿉니다:

openssl req -x509 -new -nodes -key rootCA.key -days 3650 -out rootCA.pem -subj "/CN=jhkangROOT"

2. 중간 CA를 생성합니다:

중간 CA 개인 키를 생성합니다:

openssl genrsa -out intermediateCA.key 2048

중간 CA 인증서 서명 요청(CSR)을 생성합니다:

YOUR_INITIALS를 실제 이니셜로 바꿉니다:

openssl req -new -key intermediateCA.key -out intermediateCA.csr -subj "/CN=jhkangCA"

루트 CA의 개인 키로 중간 CA의 CSR에 서명하여 중간 CA 인증서를 받습니다:

openssl x509 -req -in intermediateCA.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out intermediateCA.pem -days 3650

3. 사용자 인증서를 만듭니다:

사용자 개인 키를 생성합니다:

openssl genrsa -out user.key 2048

사용자 CSR(인증서 서명 요청)을 생성합니다:

YOUR_INITIALS를 실제 이니셜로 바꿉니다:

openssl req -new -key user.key -out user.csr -subj "/CN=jhkang"

중간 CA의 개인 키로 사용자의 CSR에 서명하여 사용자 인증서를 받습니다:

openssl x509 -req -in user.csr -CA intermediateCA.pem -CAkey intermediateCA.key -CAcreateserial -out user.pem -days 365

4. 확인(선택 사항):

루트 CA에 대해 사용자 인증서를 확인하여 신뢰 체인이 손상되지 않았는지 확인할 수도 있습니다:

openssl verify -show_chain -CAfile rootCA.pem -untrusted intermediateCA.pem user.pem

이 단계가 끝나면 과제를 위해 제출할 다음 인증서를 갖게 됩니다:

rootCA.pem
intermediateCA.pem
user.pem

과제 2

• rootCA 인증서만 install
  • install 결과화면 캡처 1-1.jpg

---

1. rootCA 인증서를 PEM에서 DER 형식으로 변환합니다

먼저 jhkangROOT.pem 인증서를 PEM 형식에서 DER 형식으로 변환하고 jhkangROOT.crt로 저장합니다:

openssl x509 -in jhkangROOT.pem -inform PEM -out jhkangROOT.crt

2. 인증서 가져오기 폴더를 만듭니다(없는 경우):

다음 명령은 /usr/local/share/ca-certificates 디렉터리가 존재하는지 확인합니다. 이미 있는 경우 다시 만들지 않습니다:

sudo mkdir -p /usr/local/share/ca-certificates

3. 변환된 rootCA 인증서를 지정된 디렉터리에 복사합니다:

이제 jhkangROOT.crt 파일을 /usr/local/share/ca-certificates 디렉터리에 복사합니다:

sudo cp jhkangROOT.crt /usr/local/share/ca-certificates

4. 시스템의 CA 인증서 저장소를 업데이트합니다:

이 명령은 새로 추가된 인증서를 확인하는 것을 포함하여 시스템의 CA 인증서 저장소를 업데이트합니다:

$ sudo update-ca-certificates

5. 설치를 확인합니다:

이제 rootCA 인증서가 /etc/ssl/certs 위치에 설치되어 있어야 합니다. 인증서가 있는지 확인할 수 있습니다:

$ ls /etc/ssl/certs | grep jhkangROOT

모든 것이 잘 되었다면 출력에 실제 인증서를 가리키는 jhkangROOT.pem 심볼 링크가 표시되어야 합니다.

이 단계를 수행하면 시스템에 jhkangROOT 인증서를 설치한 것이며, 시스템의 인증서 저장소에 의존하는 시스템 유틸리티 및 애플리케이션에서 신뢰할 수 있게 됩니다.

과제 3

인증서 체인 verify (1점)
• -CAfile 옵션 빼고, -untrusted 옵션만 사용
• verify 명령 및 결과 화면 캡쳐 1-2.jpg

• 중간 CA
  - 옵션: -ext 파일명

---

인증서 만들기/서명 절차 중에 v3 확장을 추가하는법

1. 확장 파일 만들기:

먼저 중간 CA에 대한 확장 파일을 만들어 보겠습니다. 파일 이름은 intermediateCA.ext입니다. 파일에 다음 내용을 넣습니다:

intermediateCA.ext vi


[ v3_ca ]
basicConstraints = critical,CA:TRUE

2. 확장자로 중간 CA를 다시 서명합니다:

이제 확장 파일을 사용하여 루트 CA의 개인 키로 중간 CA의 CSR에 다시 서명합니다. 그러면 확장자가 v3인 새 중간 CA 인증서가 만들어집니다:

openssl x509 -req -in intermediateCA.csr -CA jhkangROOT.pem -CAkey rootCA.key -CAcreateserial -out jhkangCA.pem -days 3650 -extfile intermediateCA.ext -extensions v3_ca

3. 인증서 체인을 확인합니다:

이제 중간 CA 인증서에 필요한 v3 확장이 있으므로 확인을 진행할 수 있습니다:

openssl verify -show_chain -untrusted jhkangCA.pem jhkang.pem

이 명령은 인증서 체인을 확인합니다. 중간 인증서에 -untrusted 옵션을 제공하면, OpenSSL은 이 인증서를 사용하여 jhkang.pem 최종 엔터티 인증서에서 시스템의 신뢰할 수 있는 루트 CA까지 체인을 완성합니다. 이미 시스템에 신뢰할 수 있는 루트 CA로 jhkangROOT.pem을 설치했으므로 OpenSSL은 이를 인식합니다.

중간 CA 인증서가 CA로서 유효하려면 기본Constraints=CA:TRUE 확장자를 가져야 합니다. 이 단계는 체인의 무결성을 보장합니다.