이전 기사 " 개발자를 위한 실용적인 암호화 - 디지털 인증서 "에서 디지털 인증서를 소개했지만 사용자가 발급된 디지털 인증서를 신뢰할 수 있도록 여기에서 CA 센터를 도입해야 합니다.
CA(Certificate Authority) 인증 센터는 PKI(공개 키 인프라) 공개 키 인프라 기술을 사용하여 네트워크 ID 인증 서비스를 제공하는 조직입니다. CA는 시민 사회 또는 정부 기관이 될 수 있습니다. CA는 전자인증서 발급 및 관리를 담당하는 기관으로 권위 있고 공정하며, 그 역할은 여권 대행사와 같이 우리 실생활에서 인증서를 발급하는 회사와 같습니다.
루트 CA 신뢰 모델
전 세계적으로 광범위한 사용자에 직면해 있는 상황에서 단 하나의 CA만으로는 분명히 충분하지 않습니다. PKI는 동일한 CA 관리 도메인 내 또는 다른 CA 관리 도메인 간의 신뢰 관계의 설정 및 이전 프로세스를 설명하고 분석하는 데 사용되는 "신뢰 모델"을 도입합니다. PKI 신뢰 모델은 주로 엄격한 계층적 신뢰 모델이라고도 하는 루트 CA 신뢰 모델을 채택합니다.
이 신뢰 모델에서는 CA 센터를 여러 수준으로 나눌 수 있으며 모든 수준의 CA 센터 간에 엄격한 계층 관계가 있습니다. -CA. 루트 CA의 디지털 인증서는 자체적으로 발급되며 자체 서명된 인증서이며 하위 CA의 디지털 인증서는 상위 CA에서 발급합니다. 트러스트 앵커는 루트 CA 또는 하위 CA일 수 있습니다.
위 그림에서 사용자 X의 신뢰 앵커는 루트 CA이므로 하위 CA1을 신뢰할 수 있으므로 사용자 A의 인증서를 신뢰할 수 있습니다.신뢰 체인은 루트 CA -> 하위 CA1 -> 사용자 A의 인증서 입니다. 사용자 Y의 신뢰 앵커는 하위 CA2이므로 하위 CA4를 신뢰할 수 있으므로 사용자 D의 인증서를 신뢰하고 신뢰 체인은 하위 CA2 -> 하위 CA4 -> 사용자 D의 인증서 입니다.
위의 그림에 현혹되지 마십시오. 세상에는 하나 이상의 루트 CA가 있습니다. 실제 세계의 CA는 다중 루트 CA 신뢰 모델 이라고 말해야 합니다 .
트러스트 앵커를 설정하려면 CA 인증서를 얻어야 합니다(이전 설명에 따르면 루트 인증서, 2차 또는 3차 인증서 또는 사용자 인증서일 수 있음) 이 인증서를 얻는 방법은 무엇입니까? 가짜 인증서를 받을 수 있나요? 사실 이 질문에 대한 답은 매우 간단하며 우리의 예상을 뛰어넘는 것일 수 있습니다. 즉, 미리 설정된 루트 인증서입니다.
사전 설정된 루트 인증서
이전 CA 모델에 따르면 응용 프로그램은 모든 CA 인증서를 미리 설정할 필요는 없지만 최상위 CA의 인증서(보통 루트 인증서라고 함)와 최상위 CA 센터의 수만 미리 설정하면 됩니다. 세계는 약 12개로 제한되어 있으므로 저장 문제는 없습니다. 물론 시스템에서 미리 설정해 놓은 루트 인증서를 보면 그보다 훨씬 많은 숫자가 나오는 것을 알 수 있습니다. 프로그램 처리의 편의를 위해 일부 보조 CA 인증서도 미리 설정할 수 있기 때문입니다. 예를 들어, 중국 CA 센터는 세계에서 유일한 2차 CA 센터일 수 있으며, 우리는 종종 중국 CA 센터에서 발행한 인증서를 확인합니다.이때 이러한 2차 CA 인증서는 미리 설정되어 있어 검증 체인이 너무 많은 것을 방지할 수 있습니다. 인증서 검증 기간이 길어지고 효율성이 향상됩니다.
루트 인증서가 저장되는 형식과 저장 위치는 애플리케이션 구현과 관련이 있습니다. 브라우저를 예로 들면, 크롬 윈도우 버전에서 사용하는 윈도우 시스템 인증서 저장 영역과 인증서 처리도 윈도우 CryptoAPI를 호출하는 것이다. Chrome Linux 버전의 루트 인증서는 NSS 데이터베이스에 저장됩니다. Android 버전의 Chrome 브라우저에서는 Android 시스템의 사전 설정된 인증서를 사용합니다. 그리고 버전 업그레이드에 따라 이러한 정책도 조정될 수 있습니다.
루트 인증서를 사전 설정하는 방법에도 특정 단점이 있습니다. 즉, 세계 최고의 CA 센터가 변경되지 않는다고 가정합니다. 실제로 인터넷상의 전자인증서에 대한 수요가 증가함에 따라 최상위 CA 센터도 확장되고 있어 새로운 CA센터에서 발급한 인증서를 기존 시스템에서 인식하지 못하는 경우가 발생하고 있다. 또한 이러한 권한 있는 CA 센터에서 발급하지 않은 인증서를 신뢰하는 경우도 있습니다. 예를 들어, 초기 12306 웹사이트는 CA 센터에서 발급한 인증서 대신 자체 서명 인증서를 사용했습니다.
따라서 대부분의 소프트웨어는 인증서 관리 기능을 제공하며 인증서를 가져올 수 있습니다. 다음 그림은 크롬 브라우저의 인증서 관리 인터페이스입니다.
크롬 브라우저와 같은 일부 소프트웨어는 의심스러운 인증서를 발견할 때 신뢰 여부를 선택할 수 있는 더 유연하고 편리합니다. 신뢰를 선택하면 계속 방문할 수 있습니다.
따라서 인증서는 본질적으로 신뢰 문제입니다 브라우저와 운영 체제가 인증서를 미리 설정하는 이유는 개발자가 이러한 CA 센터와 발급한 인증서를 신뢰하기 때문입니다. 다른 경우에 일부 소프트웨어는 사용자가 브라우저와 같은 선택을 할 수 있도록 하는 반면 일부 소프트웨어는 플레이어와 같은 선택을 제공하지 않고 신뢰할 수 없는 인증서를 직접 거부합니다.
국가 비밀 CA 센터 구축
CA센터는 굉장히 큰 이름처럼 들리는데 사실 개인도 CA센터를 수료하고 증명서를 발급받을 수 있습니다.물론 테스트용으로는 문제가 되지 않습니다. 바보.
현실 세계의 CA는 계층적으로 관리되며 계층은 여러 계층을 가질 수 있습니다. 단순성을 위해 이 문서에서는 특히 다음과 같은 3단계 CA 관리만 시뮬레이션합니다.
루트 CA -> 서버 CA -> 서버
루트 CA는 루트 CA 인증서가 있는 기본 CA이고, 서버 CA는 보조 CA이고, CA 인증서는 루트 CA에서 발급하고, 서버는 최종 사용자이고, 인증서는 서버 CA에서 발급합니다. 물론 루트 CA도 서버에 직접 인증서를 발급할 수 있으며, 이는 CA 수준의 요구 사항을 설명하기 위해 만들어진 가정입니다.
루트 CA 인증서 만들기
SM2 개인 키 생성:
$ gmssl ecparam -genkey -name sm2p256v1 -text -out rootkey.pem
루트인증서의 개인키는 rootkey.pem에 저장되어 있으니 잘 보관하시기 바랍니다.
인증서 요청 생성:
$ gmssl req -new -key rootkey.pem -out rootreq.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CN]:
State or Province Name (full name) [Some-State]:Hubei
Locality Name (eg, city) []:Wuhan
Organization Name (eg, company) [Internet Widgits Pty Ltd]:China LianTong
Organizational Unit Name (eg, p) []:
Common Name (e.g. server FQDN or YOUR name) []:www.china_liantong.com
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
위의 명령은 인증서가 자체 서명되고 개발 테스트용으로만 사용되기 때문에 몇 가지 정보를 요구할 것입니다. 무엇을 입력하든 상관없습니다.
다음 내용으로 certext.ext 텍스트 파일을 만듭니다.
[ v3_ca ]
basicConstraints = CA:true
[ usr_cert ]
subjectAltName = DNS:localhost
"CA:true" 이 확장은 발급된 인증서가 CA 인증서인지 여부를 지정하는 데 사용됩니다.
인증서 생성:
$ gmssl x509 -req -days 365 -in rootreq.pem -signkey rootkey.pem -extfile certext.ext -extensions v3_ca -out rootcert.pem
Signature ok
subject=C = CN, ST = Hubei, L = Wuhan, O = China LianTong, CN = www.china_liantong.com
Getting Private key
생성된 루트 인증서 파일은 rootcert.pem입니다.
참고: 위의 명령줄 매개변수에는 위의 certext.ext 파일의 v3_ca 섹션에 있는 확장 항목을 지정하는 추가 -extensions v3_ca 매개변수가 있습니다.
서버 CA 인증서 발급
위의 단계와 마찬가지로 다음은 명령에 대한 직접적인 요약입니다.
$ gmssl ecparam -genkey -name sm2p256v1 -text -out serverCAkey.pem
$ gmssl req -new -key serverCAkey.pem -out serverCAreq.pem
$ gmssl x509 -req -days 365 -in serverCAreq.pem -extfile certext.ext -extensions v3_ca -CA rootcert.pem -CAkey rootkey.pem -CAcreateserial -out serverCAcert.pem
세 번째 명령에는 더 많은 -CA 및 -CAkey 매개변수가 있어 루트 인증서와 CA의 개인 키가 사용됨을 나타냅니다.
이렇게 하면 서버 CA 인증서와 개인 키를 사용하여 사용자 인증서를 발급할 수 있습니다.
서버 인증서 발급
위의 단계와 마찬가지로 다음은 명령에 대한 직접적인 요약입니다.
$ gmssl ecparam -genkey -name sm2p256v1 -text -out serverkey.pem
$ gmssl req -new -key serverkey.pem -out serverreq.pem
$ gmssl x509 -req -days 365 -in serverreq.pem -extfile certext.ext -extensions usr_cert -CA serverCAcert.pem -CAkey serverCAkey.pem -CAcreateserial -out servercert.pem
참고: 세 번째 명령의 -extensions에서 제공하는 매개변수 값은 certext.ext 파일의 usr_cert 섹션에 있는 확장 항목에 해당하는 usr_cert이며 일반적으로 주어진 서버의 DNS 이름이 필요합니다. 또한 리프 노드의 인증서와 CA 인증서가 여전히 일부 다른 속성을 가지고 있음을 알 수 있습니다.
이러한 방식으로 생성된 server.pem에는 테스트에 사용할 수 있는 전체 인증서 체인을 포함하여 루트 인증서, 서버 CA 인증서 및 서버 인증서가 포함됩니다. 크롬 브라우저에서 루트 인증서를 가져올 수 있습니다.
인증서 체인
브라우저에서 인증서 정보를 볼 수 있으며 일반적으로 인증서는 다단계 상태를 나타냅니다.
서버는 CA에서 발급한 서버 엔터티 인증서로 구성하고 클라이언트(브라우저 또는 운영 체제)는 루트 인증서로 미리 설정되어 있습니다. 이제 문제는 중간 인증서를 얻는 방법입니다.
X.509 표준에 따라 서버는 전체 인증서 체인(루트 인증서 제외)을 보내야 합니다. 서버 측에서 보낸 인증서가 불완전한 경우 일부 클라이언트는 완전한 인증서 체인을 구축하려고 시도할 수 있지만 일부 브라우저는 이를 수행하지 않을 수 있으며 전체 HTTPS 프로토콜 핸드셰이크가 실패합니다.
서버 엔터티 인증서를 기반으로 전체 인증서 체인을 찾는 방법은 매우 간단하며, 브라우저는 서버 엔터티 인증서에서 CA 키 식별자(Authority Key Identifier)를 획득한 후 상위 중간 인증서 파일을 획득하고 그런 다음 중간 인증서의 CA 키를 전달합니다.식별자는 루트 인증서를 얻을 때까지 반복됩니다.
전체 인증서 체인을 보내는 서버의 장점은 핸드셰이크 속도를 향상하고 브라우저가 다른 중간 인증서를 검색할 필요가 없으므로 HTTPS 핸드셰이크 프로세스의 속도를 높일 수 있다는 것입니다.
확인 절차:
브라우저는 서버 엔터티 인증서의 상위 수준 인증서(예: B 인증서)에서 공개 키를 획득하여 서버 엔터티 인증서의 서명을 확인하는 데 사용됩니다. 인증서 확인이 실패합니다.
브라우저는 B 인증서의 서명을 확인하는 데 사용되는 B 인증서(C 인증서 등)의 상위 인증서에서 공개 키를 얻습니다. 확인에 성공하면 계속 진행하고, 그렇지 않으면 인증서 확인을 계속합니다. 실패합니다.
확인 프로세스는 브라우저가 특정 인증서의 발급자와 사용자가 동일한 사람임을 발견할 때까지 계속 반복됩니다. 즉, 루트 인증서가 발견되었음을 의미합니다. 루트 인증서의 서명을 확인하는 것은 루트가 아닌 인증서의 서명을 확인하는 것과 동일하지 않습니다. 루트 인증서의 서명을 확인하는 데 사용되는 공개 키는 루트 인증서에 있지만 서명을 확인하는 데 사용되는 공개 키는 루트가 아닌 다른 인증서는 상위 인증서에서 가져온 것입니다. , 루트 인증서는 자체 공개 키를 사용하여 서명을 확인합니다. 확인이 성공하면 전체 인증서 체인의 확인이 성공한 것입니다.
인증서 무결성 검사
X.509 표준은 인증서 검증 표준을 지정하지 않으며 브라우저마다 인증서 검증 규칙이 다릅니다.일반적으로 검증은 주로 4가지 측면을 포함합니다.
인증서 체인의 유효성 검사. 주로 각 인증서의 서명을 반복적으로 확인하고 최종적으로 자체 서명된 루트 인증서를 찾는 것입니다.브라우저는 루트 인증서를 통합하므로 루트 인증서의 공개 키를 완전히 신뢰하여 최종 서명 확인을 완료할 수 있습니다. 그러나 성공적인 서명 확인은 서버 인증서가 실제로 루트 인증서로 서명되었음을 의미할 수 있으며 인증이 성공했음을 의미하지는 않습니다.
서버 엔터티 인증서 확인. 주요 검증은 다음과 같습니다.
(1) 브라우저가 접근하는 도메인 이름이 인증서 SAN(Subject Alternative Name) 확장에 포함된 도메인 이름과 일치하는지 여부, 일치하지 않으면 검증에 실패합니다.
(2) 날짜 검증, 인증서는 유효기간을 포함하며 유효시간은 {notBefore, notAfter} 범위 내이며, 인증서가 만료되면 검증에 실패합니다.
(3) 인증서 확장 확인(선택 사항). 예를 들어 확장 Critical이 True로 표시된 경우 클라이언트는 확장을 올바르게 처리해야 합니다. 그렇지 않으면 유효성 검사가 실패합니다. 다른 예로, 브라우저는 일반적으로 Key Usage 확장을 확인하는데, 확장에 해당하는 값에 Digital Signature와 Key Encipherment가 포함되어 있지 않으면 확인이 실패합니다.
중간 인증서.
(1) 날짜 확인, 확인 인증서의 유효 기간.
(2) 인증서 확장 Critical이 True로 식별되면 확인해야 합니다.
(3) 중간 인증서도 공개키를 포함하고 있으며, 공개키의 목적을 검증할 필요가 있습니다. 검증 방법은 키 사용 확장자를 결정하는 것입니다. 확장자에 해당하는 값에 디지털 서명(디지털 서명)이 포함되어 있지 않은 경우 ), 인증서 서명(인증서 서명), CRL 서명(CRL 서명), 확인에 실패했습니다.
(4) 기본 제약 확장을 확인하고 중간 인증서가 인증서를 발급할 수 있는지 확인하고 발급이 허용되지 않으면 확인이 실패합니다.
해지 상태 확인. 유효성 검사 논리는 매우 복잡하며 일부 브라우저는 해지 상태 확인을 포기할 수 있습니다. 서버 엔터티 인증서와 중간 인증서 모두 해지 상태를 확인해야 하지만 확인 방법은 브라우저에 따라 다르며 TLS/SSL 프로토콜의 표준이 아닙니다.
요약
"개발자를 위한 실용적인 암호화" 시리즈 기사가 끝났습니다. 실제로 네트워크 보안 및 시스템 보안은 암호화 및 암호 해독, 서명, 인증서 등을 훨씬 능가하지만 암호화는 네트워크 보안의 기초입니다. 암호화에 대한 지식을 보완하면서 네트워크 보안에 대한 이해도를 높이고 나중에 국가기밀, 네트워크 보안, HTTPS, HTTP/2 등에 대한 연구를 수행하겠습니다. 토론과 교류에 오신 것을 환영합니다.
