PKI·인증서·키 생명주기

인증서는 멀쩡한데 연결을 허용하면 안 되는 경우

문서 서비스의 서버가 인증서를 보여 주었다. 서명도 맞고 유효기간도 남았지만 인증서의 이름은 접속하려던 서버와 다르다. 다른 날에는 이름까지 맞았지만 폐지 상태를 확인할 자료가 오래되어 판단할 수 없었다. 둘을 모두 “인증서 있음”으로 처리하면, 파일의 존재를 신뢰 판단으로 바꾸는 오류가 된다.

앞 절의 지급 문서 M을 받는 조직 B는 먼저 docs.example.org에 접속해 문서를 읽고, 이후 저장키 교체 때 같은 M을 옛 백업에서 복구해야 한다. 접속 서버의 개인키, 문서의 데이터키, 데이터키를 포장하는 키는 같은 이름의 비밀값이 아니다. 이 한 서비스에서 “누구에게 접속했는가”와 “어떤 자료를 다시 읽을 수 있는가”를 차례로 확인한다.

키를 주기적으로 바꾸는 운영도 비슷하다. 새 키로 새 문서를 저장한 사실만으로 옛 문서와 백업을 복구할 수 있다는 결론이 나오지 않는다. 이 절은 누구의 키를 무엇에 신뢰할지와, 사용을 멈춘 키를 언제까지 어떤 용도로 보존할지를 연결한다.

공개키 도구와 접속 대상 확인을 되짚기

암호 기본도구의 공개키와 서명 연산만으로는 그 키를 누구의 어떤 용도에 신뢰할지 결정할 수 없다. TLS·PKIX에서는 인증경로 검증과 접속하려는 서비스 이름의 일치를 따로 확인했다. 여기서는 그 근거를 발급·배포·교체·폐지·보존하는 운영을 붙인다.

1. 공개키 신뢰를 운영하는 체계

공개키 기반구조(PKI)는 공개키와 주체·용도의 연결을 발급 정책, 인증서와 신뢰 기준, 상태 정보, 키 관리와 기록을 통해 운영하는 체계다. 키 생명주기는 키의 생성·활성 사용·사용 제한·보존·폐기와 그 전이를 용도별로 관리하는 과정이다. 이 절에서 PKI·키 생명주기는 연결의 신뢰와 키의 운영상 사용 가능성을 함께 판단하는 범위다.

인증기관(CA)은 정한 발급 정책에 따라 공개키와 주체 정보를 묶은 인증서에 서명하는 발급자다. 등록기관(RA)은 위임된 절차에 따라 신청자의 신원·권한 등 등록 정보를 확인하는 역할이다. 신뢰 앵커는 검증자가 미리 신뢰하도록 설정한 이름·공개키 등의 검증 출발 정보다.[CT-C03]

인증서를 파일 형태로 받은 것과 인증서에 해당하는 개인키를 실제로 보유한 상대와 통신하는 것은 다르다. 발급과 검증에 사용할 신원·용도 정책을 정하고, 인증 프로토콜에서는 개인키 보유를 증명하는 절차도 성공해야 한다. 자기서명된 루트 인증서가 파일로 전달되었다고 자동으로 신뢰 앵커가 되는 것은 아니다.

2. 인증서 검증의 질문을 분리한다

인증서에는 발급자, 공개키, 일련번호, 유효기간, 이름과 용도·제약을 나타내는 정보가 들어 있다. 발급자의 서명 검증은 연결된 정보를 확인하는 한 단계다. 신뢰 앵커에 이르는 경로를 구성한 뒤, 각 인증서의 서명·시각·CA 자격·경로 길이·이름 제약 등 적용되는 규칙과 중요한 확장 필드를 검증해야 한다. 이해하지 못하는 필수 확장을 무시하거나 전달된 루트를 임의로 신뢰 목록에 넣지 않는다.[CT-C03]

그 뒤 접속하려던 서비스의 이름을 검증된 인증서의 허용된 이름과 비교한다. 기대한 이름은 접속 설정 같은 신뢰 가능한 입력에서 얻어야 하며, 상대 인증서의 이름을 읽어 기대값을 만들어서는 안 된다. RFC 9525의 서비스 신원검증에서는 Common Name을 서비스 식별자로 사용하는 방식을 허용하지 않는다. 유효한 경로라는 사실이 이름 일치나 업무 권한을 대신하지 않는다.[CT-C04]

실제 검증은 검토된 인증서·TLS 라이브러리의 경로 검증 기능에 맡긴다. 아래 표는 결과 해석을 배우는 예이며, 문자열 비교 몇 개로 인증서 검증기를 구현하라는 명세가 아니다. 사용 목적 제한, 유효한 폐지 근거, 알고리즘 정책과 필요한 프로토콜 검증도 확인해야 한다.

발급과 이용의 흐름은 한 방향의 도장이 아니다

상태 공표와 모든 검증자의 반영 사이에는 지연이 있을 수 있다. 인증서를 폐지했다고 이미 열린 채널이나 애플리케이션 세션이 모두 즉시 종료된다고 가정하지 않는다. 영향 채널·세션을 식별하고 종료 여부를 확인하는 운영은 따로 필요하다.

3. 직접 판정: 성공·거부·판단 불가

자체 사례 CT-V1에서 기대한 서비스 이름은 docs.example.org다. 아래 값은 실제 인증서 파서가 아니라 앞의 검증 절차를 수행한 모형 결과다. 시각은 UTC로 고정한다. C1의 인증서 유효기간은 2026-09-01 00:00:00부터 2026-09-30 00:00:00까지이며 RFC 5280의 유효기간 비교는 양 끝을 포함한다. 이것만으로 인증서 전체가 유효해지는 것은 아니다.[CT-C03]

C1을 정확히 2026-09-30 00:00:00에 보면 이 유효기간 조건은 통과하지만, 1초 뒤에는 실패한다. 시스템 시각이 믿을 수 없다면 시각 검증도 통과했다고 적지 않는다. C3의 “판단 불가”는 “폐지되지 않음”과 다르다. 이 가상 문서 서비스는 필요한 상태 근거가 없을 때 새 연결을 보류하도록 선택했으며, 이는 모든 응용의 보편적 실패 처리 규칙이라는 주장이 아니다.

C1도 프로토콜에서 상대 개인키 보유를 확인하기 전에는 접속 인증 완료가 아니다. 인증된 연결 뒤에 문서 읽기 권한이 없으면 문서 제공은 별도로 거부한다. 서로 다른 판정을 하나의 “인증서 성공률”로 합치지 않는다.

3.1 폐지 결정 시각과 효력이 관측된 시각

인증서 폐지목록(CRL)은 발급자 등이 서명하여 폐지된 인증서와 상태 시각 정보를 제공하는 목록이다. 검증자는 서명, 적용 범위, 발행·갱신 시각 등 필요한 조건을 확인해야 하며 오래된 목록의 부재 항목을 현재의 미폐지 증거로 무조건 사용하지 않는다.[CT-C03]

자체 관측 CT-R1은 같은 날 UTC 10:03에 폐지를 결정하고 10:04에 새 상태를 공표했으며 한 클라이언트가 10:08에 이를 반영했다고 가정한다. 그 클라이언트의 결정 후 반영 지연은 5분이고, 공표 후 지연은 4분이다. 10:04에 중앙 문서가 갱신되었다는 사실을 모든 클라이언트의 차단 완료로 보고하지 않는다. 이 관측 하나로 최대 지연이나 전체 반영률을 추정하지도 않는다.

단기 인증서로 유효기간을 줄이는 대안은 노출 창을 줄이는 데 기여할 수 있지만 이미 열린 세션, 시간 동기화, 갱신 장애를 없애지는 않는다. 공표만 빨리 할지, 조회·캐시 정책을 바꿀지, 긴급 세션 종료를 추가할지는 보호 대상과 중단 비용을 함께 보고 결정한다.

4. 데이터를 잠그는 키와 그 키를 보호하는 키

데이터 암호키(DEK)는 이 사례에서 문서 내용의 암호화·복호화에 사용하는 대칭키다. 키 암호키(KEK)는 다른 키를 암호학적으로 보호하는 데 사용하는 키다. 키 포장(wrapping)은 키의 기밀성과 무결성을 보호하여 저장·전달할 수 있게 하는 처리다. 포장을 푸는 연산도 검증을 통과해야 하며, 검증된 키 관리 기능을 사용한다.[CT-C05]

DEK와 KEK는 서비스 연결용 개인키나 문서 서명용 개인키와 용도가 다르다. 모두 “키”라는 이름으로 한 권한에 묶으면 저장소를 읽는 운영자에게 문서 해독 권한까지 주기 쉽다. 운영자는 키 값 대신 키 식별자·버전·용도·상태를 조회하고, 실제 키 연산은 명시된 주체와 용도에 한해 허용한다.

중앙 키 관리 서비스는 통제와 기록을 모으지만 그 서비스의 장애·권한 집중도 중요한 의존성이 된다. 복구 가능한 키 백업과 제한된 복구 권한을 마련하고 실제로 보호 문서를 읽어 보아야 한다. 안전한 키 보관 장치가 있다는 사실만으로 잘못 허용한 애플리케이션 호출까지 막는 것은 아니다.

5. 직접 계산: 포장키 교체와 데이터키 노출

자체 장부 CT-K1은 D1이라는 DEK 하나가 문서 60개를, 독립된 D2라는 DEK 하나가 문서 40개를 보호한다고 정한다. 각 키의 여러 문서는 앞 절의 키별 논스 조건을 지킨다. 포장된 DEK는 문서마다 중복 저장하지 않고 아래 두 키 레코드에 한 번씩 저장한다. W1은 두 DEK를 포장하는 KEK이고, 문서는 각 DEK 식별자를 참조한다.

CT-K1을 푸는 순서

1. 먼저 실제 키 값과 저장 레코드를 나눈다. W1은 두 DEK를 보호하고 WD1·WD2는 그 결과를 저장한 두 레코드다. 문서 100개가 각각 포장 레코드를 가진다는 조건은 없다.
2. 정상 포장키 교체에서는 DEK D1·D2의 값이 유지된다. 따라서 본문이 요구하는 DEK는 같고 두 포장 레코드만 W2 보호로 바뀐다. 이 때문에 본문 재암호화가 0개다.
3. D1 노출에서는 노출된 D1 대신 새로운 데이터키를 사용해야 한다. D1을 새 포장으로 덮는 것은 공격자의 복사본을 없애지 못하므로, 새 DEK와 D1 의존 문서 60개의 재암호화가 필요하다.
4. 두 경우 모두 현재 문서 읽기와 옛 백업 읽기를 따로 시험한다. 새 포장 레코드를 읽었다는 결과만으로 W1에 의존하는 옛 백업의 복구 경로가 사라졌다고 판단하지 않는다.

정상적인 W1→W2 교체: 노출 사고가 없고 D1·D2를 그대로 쓰는 조건에서 WD1·WD2를 풀어 검증한 뒤 W2로 다시 포장한다. 바뀌는 포장 레코드는 2개, 본문 재암호화 문서는 0개다. “문서가 100개니 포장도 반드시 100번”이라는 결론은 이 장부 구조에서는 틀린다. 단, 옛 백업에 W1 포장 레코드가 남아 있다면 현재 두 레코드의 교체만으로 W1을 즉시 폐기할 수 없다.

D1의 실제 키 값 노출: W2로 D1을 다시 포장해도 공격자가 이미 가진 D1은 달라지지 않는다. 노출 경로를 차단하고 독립된 새 DEK를 생성해 D1 의존 문서 60개를 재암호화·검증하고 참조를 전환해야 한다. D2의 40개는 이 가정의 직접 재암호화 대상이 아니지만 노출 범위를 재조사한다. 공격자가 이미 읽은 평문을 새 암호화로 회수할 수는 없다.

W1과 옛 포장값의 동시 노출: 공격자가 WD1·WD2까지 확보했다면 D1·D2 모두 노출될 수 있으므로 100개 문서와 관련 백업을 영향 범위로 조사한다. W1의 이름만 바꾸거나 포장만 갱신하고 사고를 종결하지 않는다. 정상 교체와 사고 복구는 같은 작업 목록이 아니다.

6. 사용 중지·보존·폐기를 같은 상태로 만들지 않는다

NIST SP 800-57 Part 1 Rev.5는 새 보호를 적용하는 기간과 이미 보호된 정보를 처리하는 기간을 구분한다. 비활성화된 키는 새 보호에 쓰지 않으면서, 키 종류와 조건에 따라 기존 정보를 처리하는 데 제한적으로 사용할 수 있다. 모든 키를 같은 상태표나 기간으로 운영한다는 뜻은 아니다.[CT-C05]

다음은 CT-K1의 데이터키 운영을 위한 자체 정책표다. 개인 서명키의 보존 정책을 이 표에서 그대로 복사하지 않는다.

키를 폐기하기 전에는 그 키를 요구하는 본문, 포장 레코드, 오래된 백업과 복구 경로가 더 이상 필요한지 확인한다. 현재 운영 파일만 새 키로 읽힌다는 시험은 옛 백업 복구시험을 대신하지 못한다. 서명 검증용 공개키·인증서·검증 시각의 기록 보존과 서명 생성용 개인키의 보존 필요성도 구별한다.

7. 운영 산출물: 키 대장과 교체 승인서 CT-O1

키 대장에는 식별자·실제 버전, 용도, 책임자, 허용 연산 주체, 신규 사용 종료 조건, 의존 문서·포장 레코드·백업, 이상 시 연락·중지 경로를 적는다. 인증서 대장에는 발급자·일련번호·서비스 이름·유효기간·배포 위치·갱신 담당·폐지 반영 확인 위치도 연결한다. 비밀키 값은 대장에 쓰지 않는다.

CT-K1의 정상 교체 승인서는 다음 순서를 갖는다. 키 관리자가 W2를 생성하고 권한·포장 해제 시험을 확인한다. 서비스 담당자는 W2 포장 레코드를 배치한 뒤 D1·D2 양쪽 문서를 읽어 키·태그·문맥 검증을 확인한다. 기존 백업 복구 담당자는 W1 의존 사본과 보존 계획을 대조한다. 업무 담당자는 전환 중 누락·중복·읽기 오류가 없는지 확인한 후 신규 포장을 W2로 제한한다. 보안 담당자는 W1의 신규 사용을 중지하고 필요한 옛 복구 용도만 제한적으로 남긴다.

포장 해제·본문 검증 실패나 대장과 실제 키 버전 불일치가 있으면 전환을 완료 처리하지 않는다. 정상 교체의 복귀는 기존 키가 노출되지 않았고 허용기간·용도 안에 있을 때에만 검토한다. 노출된 키로 되돌아가서 가용성을 회복했다고 보고하는 선택은 하지 않는다. 폐기 시점은 의존성 해소와 승인된 보존 조건을 확인한 뒤 정한다.

실패 이유를 지워서 복구하지 않는다

연결 실패에는 만료, 이름 불일치, 신뢰 설정 오류, 상태 근거 부족, 개인키 불일치가 각각 있을 수 있다. 전부 “인증서 오류”라고 쓰면 갱신만 반복하거나 이름 검증을 끄기 쉽다. CT-V1의 열별 결과, 기준 시각, 정책 버전과 사용한 상태 자료를 함께 남겨야 한다.

암호문이 복호화되지 않을 때에도 어떤 데이터키·포장키·버전이 필요한지부터 확인한다. 검증을 생략해 얻은 평문이나 새 인증서를 발급받았다는 사실이 저장 데이터의 복구 증거가 되는 것은 아니다. 복구가 확인되지 않은 문서는 미복구로 남기고 원본 증거를 손상시키지 않는다.

보안기술을 보조하는 이 절의 범위

이 절은 공개키 신뢰와 키 교체의 사용 가능성을 판단한다. 대상은 인증서 검증 결과·키 대장·포장 레코드·의존 문서다. 경계는 경로 검증·서비스 신원·업무 인가와 정상 교체·노출 복구의 구별이다. 실패 판단은 미확인 상태를 성공으로 바꾸지 않고 포장 교체와 데이터 재암호화 대상을 따로 계산하는 것이다. 전체 인증 프로토콜 구현·모든 PKI 정책 적합성·법적 효력 승인은 제외한다.

앞 절의 암호기술과 보안기술에서 설명한 보호 입력·검증 실패의 경계를 인증서·키 운영에 적용한다. 다음 자체 문제는 그 적용 범위를 연습하며 공식 기준 전체의 충족을 판정하는 문제가 아니다.

8. 자체 10점 문제: 인증서 결과 해석

CT-V1의 C1·C2·C3 판정을 설명하고, C1의 유효기간 끝 시각과 1초 뒤의 차이 및 업무 인가를 별도로 확인해야 하는 이유를 서술하라.

판단 불가를 거부와 구별하되, 이 서비스에서 새 연결을 보류한다는 운영 선택까지 적는다. 두 시각은 동일한 UTC 기준으로 비교한다.

답안을 열기 전에: 문제에 주어진 값과 판정 근거를 먼저 적고, 결과만 맞춘 항목에는 그 이유를 한 문장 더 붙인다. 이 문제와 아래 설계 문제는 자체 연습이며 공식 채점표가 아니다.

C1 → 다음 프로토콜 검증
C2 → 이름 불일치 거부
C3 → 상태 근거 부족, 새 연결 보류
시각 조건 통과 ≠ 전체 인증 완료 ≠ 문서 제공 허가

9. 자체 25점 문제: 정상 교체와 노출 사고

CT-K1에서 W1을 W2로 정상 교체하는 절차와 D1의 실제 키 값이 노출된 경우의 대응을 설계하라. 포장 레코드·문서 수, 책임자, 전환 검증, 옛 백업, 중단·복귀·폐기 조건을 포함하라.

문서 100개와 포장 레코드 2개라는 저장 구조를 먼저 읽는다. 키 이름 변경, 실제 키 변경, 본문 재암호화를 구분해야 한다.

답안을 열기 전에: 설계의 허용 조건, 담당자, 실제 확인 방법과 중단 조건을 자신의 문장으로 연결한다. 앞의 정책을 그대로 복사하기보다 문제에서 바뀐 조건이 있는지 확인한다.

10. 스스로 고치기

다른 조건에서의 판정

D1 의존 문서가 70개, D2가 30개로 바뀌면? 포장 레코드 구조가 같다면 정상 W1 교체는 여전히 2개 포장·본문 0개이고 D1 노출의 직접 본문 대상은 70개다. 장부의 서로 다른 분모를 유지한다.

인증서 상태가 새로 확인되어 C3가 미폐지라면? 나머지 조건을 다시 대조하고 프로토콜 검증을 진행할 수 있지만 업무 권한까지 생기는 것은 아니다. 판정 표에서 부족했던 증거만 갱신한다.

관측된 반영 시각이 10:12라면? CT-R1의 결정 후 지연은 9분, 공표 후 지연은 8분이다. 10:04 공표 완료를 차단 완료로 고쳐 쓰지 않는다. 시각 구별로 돌아가 확인한다.

근거와 적용 한계

CT-C03: RFC 5280 §§3.2–3.5, 4.1.2.5, 4.2, 5–6의 발급·경로·유효기간·폐지 범위. CT-C04: RFC 9525 §§1.2, 2, 6의 서비스 신원 분리·Common Name 배제·독립된 기대 식별자. 두 자료는 기존 보존 출처 ID를 재사용하고 과거 관찰일을 바꾸지 않는다.

CT-C05: NIST SP 800-57 Part 1 Rev.5, 2020-05 발행, §§5.3.5–5.3.6, 7.4와 키 유형 설명을 참조했다. 2026-09-18 확인에서 Rev.6 초안을 Rev.5 최종판과 혼동하지 않았다. 새 관찰일은 효력일이나 한국의 법적 의무일이 아니다.

CT-V1·CT-R1·CT-K1·CT-O1과 표·도식·답안은 자체 교육 자료다. 완전한 인증서 검증기, 실제 사고의 원인 확정, 모든 키 유형의 보존기간이나 법적 효력 판정으로 사용하지 않는다. 원문 도식을 복사하지 않았으며 독립 기술·권리·독자 검토는 남아 있다.

회독 때 붙잡을 결론

인증서는 신뢰 앵커·경로·서비스 이름·용도·상태와 실제 프로토콜 검증을 거쳐 해석한다. 키의 정상 교체는 노출 사고의 복구와 다르며, 포장키를 바꾸는 작업량은 본문 재암호화량과 다를 수 있다. 신규 사용 중지와 제한적 옛 자료 처리, 최종 폐기를 나누고 의존 문서·백업의 복구 가능성을 확인한다. 다음 절은 인증된 주체의 실제 행동을 역할·속성·세션 상태로 통제한다.

책을 덮고 설명하기: 접속 이름이 다른 인증서와 상태 근거가 없는 인증서를 왜 다르게 기록하는지 말한다. 이어 W1 정상 교체의 2개·0개와 D1 노출의 60개가 각각 무엇을 센 수인지 설명한다. 숫자만 기억났다면 검증 질문과 키 장부의 의존관계부터 다시 읽는다.