HSM 기반 서명

Spec PKCS#11 v3.1 Spec Spec: ISO 32000-2, §12.8 ISO 32000-2 §12.8 Spec Spec: FIPS 140-3 FIPS 140-3 Evidence § Standard-backed Evidence: Standard-backed

한눈에 보기

하드웨어 보안 모듈(HSM)은 서명 키를 프로세스 밖으로 빼내어, 요청 시 서명은 하지만 키 자체는 결코 돌려주지 않는 장치 뒤에 둡니다. 이 페이지는 NextPDF가 서명을 위해 거치는 PKCS#11 이음매, 키 경계가 정확히 어디에 놓이는지, 그리고 결과물의 어떤 부분이 장치나 사용자의 책임이 아니라 엔진의 책임인지를 설명합니다.

이것이 중요한 이유

프로세스 메모리 안의 서명 키는 그 프로세스를 읽을 수 있는 모든 것에 노출됩니다. 힙 덤프, 디버거, 로깅 실수, 또는 취약점이 있는 의존성이 그렇습니다. 일단 개인 키가 복사되면 그 키가 만든 모든 서명이 의심받게 되며, 그 키를 다시 비밀로 되돌릴 수는 없습니다. HSM의 핵심은 가져갈 복사본이 애초에 존재하지 않는다는 데 있습니다.

경계를 잘못 잡으면 조용히 큰 대가를 치릅니다. 하드웨어 기반인 것처럼 보이지만 서명을 위해 키를 메모리로 끌어오는 워크플로는 HSM의 운영 비용을 치르면서도 소프트웨어 키의 위험 프로파일을 갖습니다. 이 차이는 완성된 PDF에서 보이지 않으므로, 가정할 것이 아니라 설계 단계에서 반영하고 검증해야 합니다.

요약

• PKCS#11 표준은 민감(sensitive)하며 추출 불가능(non-extractable)으로 표시된 키 객체를 정의합니다. 그 개인 값은 토큰 밖에서 평문으로 드러날 수 없습니다. Spec Spec: PKCS#11, v3.1 §10.9 PKCS#11 v3.1 §10.9
• NextPDF는 PDF 서명 구조와 CMS 컨테이너를 구축합니다. 서명할 바이트를 PKCS#11 이음매 너머로 건네고 서명을 돌려받습니다. 키는 결코 그 이음매를 넘지 않습니다.
• 이 이음매는 안정적인 계약입니다. 스마트카드 토큰, USB HSM, 네트워크 HSM, 클라우드 KMS가 모두 동일한 계약을 충족합니다. 그 사이에서 엔진 코드는 바뀌지 않습니다.
• NextPDF는 서명 엔진 소프트웨어입니다. 장치의 하드웨어 보증, 그 검증 상태, PIN 정책, 그리고 배포는 엔진이 인증하는 대상이 아닙니다. 엔진은 장치를 사용할 뿐, 그것을 보증하지는 않습니다.

NextPDF가 접근하는 방식

이음매, 정확하게

NextPDF는 서명 조립과 서명 값 계산을 분리합니다. 조립은 엔진의 일입니다. 서명 필드를 배치하고, 파일에 공간을 예약하며, 바이트 범위를 계산하고, 서명된 속성과 함께 CMS SignedData를 구축합니다. Spec Spec: ISO 32000-2, §12.8 ISO 32000-2 §12.8

서명 값 계산은 위임됩니다. 엔진은 작은 서명 제공자 계약을 정의합니다. 이 계약은 불투명한 바이트 시퀀스(실제로는 DER로 인코딩된 서명된 속성)를 받아 원시 서명 옥텟을 반환합니다. 그 계약이 이음매입니다. PDF와 CMS 지식은 한쪽에 머물고, 키는 다른 쪽에 머뭅니다. 제공자는 로컬 소프트웨어 키의 경우 그 키를 프로세스 안에 둘 수도, 클라우드 KMS에 둘 수도, PKCS#11을 통해 하드웨어 토큰에 둘 수도 있습니다. 이음매 위쪽의 엔진 코드는 모든 경우에 동일합니다. 그 뒤의 제공자만 달라질 뿐입니다.

경계가 실제로 놓이는 지점

PKCS#11 — OASIS 암호화 토큰 인터페이스, 과거 명칭 “Cryptoki” —은 하드웨어 토큰에 대한 표준 C 인터페이스입니다. NextPDF의 하드웨어 경로는 PKCS#11로 통신합니다(직접 통신하거나, 또는 인프로세스 바인딩이 토큰을 로드할 수 없는 엔진·제공자 배포에서는 OpenSSL 명령줄 브리지를 통해 통신합니다).

토큰의 키 객체는 경계를 정의하는 두 가지 속성과 함께 생성됩니다. 키가 민감(sensitive)으로 표시되거나 추출 불가능(non-extractable)으로 표시되면, 특정 개인 속성은 토큰 밖에서 평문으로 드러날 수 없습니다. Spec Spec: PKCS#11, v3.1 §10.9 PKCS#11 v3.1 §10.9 서명 작업 자체는 장치가 수행하는 단일 토큰 호출 — C_SignInit 다음에 C_Sign — 입니다. Spec Spec: PKCS#11, v3.1 §5.10 PKCS#11 v3.1 §5.10 서명 작업을 위해 NextPDF가 다루는 평문은 서명할 바이트입니다. 돌아오는 것은 서명과 인증서입니다. 개인 키는 어느 경로에도 없습니다. 그것이 경계이며, 그 경계를 강제하는 것은 라이브러리가 아니라 토큰입니다.

1. Step 1 of 4: ISO 32000-2 §12.8 — signature dictionary, ByteRange, Contents ISO 32000-2 §12.8 — signature dictionary, ByteRange, Contents
2. Step 2 of 4: RFC 5652 CMS SignedData — the signature container RFC 5652 CMS SignedData — the signature container
3. PKCS#11 v3.1 — token interface; sensitive, non-extractable key
4. Step 4 of 4: FIPS 140-3 / ISO/IEC 19790 cryptographic module assurance (device-level, deployment-dependent) FIPS 140-3 / ISO/IEC 19790 cryptographic module assurance (device-level, deployment-dependent)

Where a hardware-backed PDF signature is grounded, in order: the PDF carrier (ISO 32000-2 §12.8), the CMS container it holds, the token interface NextPDF signs through (PKCS#11), and the module-assurance standards that describe — but do not by themselves guarantee — the device behind it.

하나의 PIN, 한 번의 재인증

PKCS#11은 키가 사용할 때마다 재인증을 요구하도록 할 수 있습니다. CKA_ALWAYS_AUTHENTICATE 속성이 설정되면, 사용자는 세션당 한 번이 아니라 각 암호화 작업마다 PIN을 다시 제시해야 합니다. Spec Spec: PKCS#11, v3.1 §10.9 PKCS#11 v3.1 §10.9 NextPDF의 PKCS#11 경로는 이에 맞게 작성되었습니다. PIN은 민감한 매개변수입니다. 로깅되거나 직렬화되지 않습니다. 세션이 기존 로그인을 보고하면, NextPDF는 다음 서명이 새로운 PIN 검사를 받도록 세션을 깨끗한 상태로 되돌립니다. 이는 서명마다 PIN을 요구하는 정책을 가진 PIV 방식 토큰에서 중요합니다. 이는 장치의 정책을 존중하는 엔진 동작이며, 그 정책을 완화하지 않습니다.

증거가 말하는 것

Evidence § Standard-backed Evidence: Standard-backed 추출 불가능한 키 속성은 NextPDF의 주장이 아닙니다. 그것은 PKCS#11 모델입니다. CKA_SENSITIVE가 참이거나 CKA_EXTRACTABLE가 거짓인 키 객체는 토큰 밖에서 그 개인 값을 평문으로 내놓지 않습니다. Spec Spec: PKCS#11, v3.1 §10.9 PKCS#11 v3.1 §10.9 NextPDF의 기여는 그 값을 결코 필요로 하지 않는 데 있습니다. 엔진은 키 재료를 요청하는 대신 토큰의 C_Sign 작업을 통해 서명합니다.

Evidence § Standard-backed Evidence: Standard-backed PDF 측면은 Spec Spec: ISO 32000-2, §12.8 ISO 32000-2 §12.8 에 근거를 둡니다. 바이트 범위 다이제스트는 서명 값을 제외한 파일 전체에 대해 계산됩니다. Contents 항목에 들어가는 서명 값은 공개 키 서명의 경우 DER로 인코딩된 CMS SignedData 객체입니다. HSM은 가장 안쪽의 서명 옥텟만 생성합니다. NextPDF는 그 주위의 모든 것을 구축하여, 표준이 정의하는 구조 안에 기록합니다.

Evidence § Standard-backed Evidence: Standard-backed 장치 보증은 Spec Spec: FIPS 140-3 FIPS 140-3 와 그 기반 표준인 ISO/IEC 19790이 기술합니다. 이들은 알고리즘 사양부터 물리적 변조 증거에 이르기까지 열한 개 요구 사항 영역에 걸쳐 점점 높아지는 네 단계의 정성적 보안 수준을 정의합니다. 이 표준들은 모듈이 어떤 수준을 주장하기 위해 충족해야 하는 바를 기술합니다. 그것은 NextPDF가 아니라 장치와 그 검증의 속성이며, ISO/IEC 19790 자체의 표현을 빌리면, 적합성만으로는 주어진 배포에서 모듈의 보안을 보장하기에 충분하지 않습니다.

Human-factors note: Human-factors note

This page deliberately states the boundary before the mechanism, and it puts the cost of getting it wrong near the top. In a safety-critical domain, the honest order is the warning first, then the how. A workflow that silently loads a key into memory fails in a way you do not see in the output, so the trap is named before the recipe. The badge row already tells you the page is standard-backed before you read a sentence of body text.

실용적인 예제

아래의 형태는 예시입니다. 복사해서 붙여 넣을 배포가 아니라 이음매를 보여 줍니다. 핵심은 엔진이 서명자를 건네받을 뿐 키를 결코 보지 않는다는 점입니다. 서명자의 sign()은 장치로 들어가는 호출입니다.

<?php

declare(strict_types=1);

use NextPDF\Contracts\HsmSignerInterface;

/**
 * Sign a PDF where the private key lives on a PKCS#11 token.
 *
 * `$hsm` is a hardware-backed signer. Its sign() delegates to the token;
 * the key never enters this process. Everything that makes the bytes a
 * valid PDF signature — field, byte range, CMS SignedData — is built by
 * the engine around the value the device returns.
 *
 * Token wiring (library path, slot, PIN, key label) is deployment
 * configuration and is intentionally out of scope here: those values are
 * operator-owned secrets, not library inputs to hardcode.
 */
function signWithToken(
    string $pdfPath,
    HsmSignerInterface $hsm,
): string {
    // The engine asks the signer only for: the certificate (to embed in
    // the CMS) and a signature over the bytes it computes. It never asks
    // for, and the contract never exposes, the private key.
    $certificateDer = $hsm->getCertificateDer();
    $chainDer       = $hsm->getCertificateChainDer();

    // Pseudocode for the engine's own assembly step: build the signature
    // dictionary + CMS SignedData, then hand the signed-attributes bytes
    // to $hsm->sign(...) and place the returned octets in /Contents.
    return nextpdf_sign_pdf(
        pdfPath: $pdfPath,
        signer: $hsm,
        certificateDer: $certificateDer,
        chainDer: $chainDer,
    );
}

이 형태에 대해 솔직한 두 가지 참고 사항이 있습니다. 인프로세스 PKCS#11 바인딩은 표준 PHP 빌드에 포함되지 않는 별도의 PHP 확장입니다. 하드웨어 배포는 이를 나중에 덧붙이는 것이 아니라 플랫폼의 일부로 설치하고 검증합니다(또는 OpenSSL 명령줄 브리지를 사용합니다). 그리고 장치에 요청하는 알고리즘은 키가 실제로 수행할 수 있는 것이어야 합니다. 구성된 알고리즘이 선택한 제공자에 대한 매핑이 없을 때, 엔진은 토큰 호출 깊숙한 곳에서 실패하는 대신 일찍 거부합니다.

흔한 오해

“HSM을 사용한다는 것은 서명이 FIPS 검증을 받았다는 뜻이다.”

아닙니다. 그 둘을 혼동하는 것이 함정입니다. HSM은 키가 존재하고 작업이 실행되는 장소입니다. FIPS 140-3 / ISO/IEC 19790 검증은 검증 프로그램을 통해 확립되어 장치(또는 특정 모듈 구성)가 보유할 수 있는 속성이며, 호출하는 라이브러리가 부여하는 것도 아니고 NextPDF가 장치를 대신해 주장하는 것도 아닙니다. NextPDF는 PKCS#11 장치를 통한 서명과 호환되며, 그 서명 경로는 범주를 대표하는 토큰들로 테스트되었습니다. 주어진 배포가 FIPS 모듈 수준으로 검증되었는지 여부는 전적으로 하드웨어, 그 인증서, 그리고 그것이 구성되고 운영되는 방식에 달려 있습니다. 실제로 가지고 있는 것에 대해 정확한 단어를 쓰십시오.

한계와 경계

이 페이지는 이음매와 그것이 의존하는 표준을 설명합니다. 이는 배포에 대한 보장이 아니며, 그 경계선은 분명하게 밝힐 가치가 있습니다.

• 엔진의 책임. 서명 필드를 구축하고, 공간을 예약하며, 바이트 범위를 계산하고, CMS SignedData를 조립하며, 서명 제공자를 호출하고, Spec Spec: ISO 32000-2, §12.8 ISO 32000-2 §12.8 에 따라 구조적으로 올바른 서명을 기록합니다. NextPDF의 하드웨어 경로는 이 목적을 위해 PKCS#11 서명 인터페이스를 준수합니다.
• 장치와 운영자의 책임. 하드웨어의 변조 저항성, 그 FIPS 140-3 / ISO/IEC 19790 검증 상태, 키 생성과 보관, PIN 정책, 슬롯 구성, 펌웨어, 그리고 물리적 보안입니다. 이 중 어느 것도 엔진이 인증하는 대상이 아닙니다.
• 테스트되었다는 것은 인증되었다는 뜻이 아닙니다. NextPDF가 대표적인 토큰 범주 — 동일한 PKCS#11 계약을 통해 도달하는 스마트카드, USB, 네트워크, 클라우드 KMS 형태 — 에 대해 검증된 경로를 가지고 있다는 것은 호환성 진술입니다. 이는 인증도, 검증된 모듈 수도, 당신의 특정 장치에 대한 주장도 아닙니다. 아래의 하드웨어 범주는 하나의 표준 인터페이스를 통과하는 통합 형태입니다. 그것들을 “이음매가 실제로 검증된 지점”으로 다루되, 직접 테스트하지 않은 모델에 대한 보장으로는 결코 다루지 마십시오.
• 포스트 양자 서명은 실험적입니다. 엔진이 토큰을 통해 포스트 양자 서명을 노출하는 경우, 그것은 옵트인이며 게이팅되고, 포스트 양자 HSM 펌웨어가 아니라 목(mock)에 대해 검증됩니다. PAdES와 AdES 암호화 스위트 카탈로그는 아직 그러한 스위트를 장기 보존용으로 인정하지 않습니다. 이를 프로덕션 준비 상태로 다루지 마십시오.

HSM-backed signing via PKCS#11 — edition availability

Edition	Availability
Core	○ Not in this edition. Core provides the signing engine and the signing-provider seam, with a local software-key provider.
Pro	○ Cloud key management — signing through managed KMS keys — is a Pro capability, described at the behaviour level only.
Enterprise	○ Available. Hardware-token signing through the PKCS#11 interface (and an OpenSSL command-line bridge for engine/provider deployments) is an Enterprise capability. Availability is a capability statement, not a certification of any device or deployment.

하나의 인터페이스를 통과하는 통합 형태

이것들은 PKCS#11 이음매가 실제로 검증된 형태입니다. 이 열은 “검증되고 인증되었거나 집계된 장치 목록”이 아니라 “통합이 어떤 모습인지”를 나타냅니다.

통합 형태	도달 방식	키 경계	보증의 귀속
Smart-card / PIV token	PKCS#11 module; per-use PIN common	On the card; non-extractable	The card and its operator
USB HSM	PKCS#11 module	On the device; non-extractable	The device and its operator
Network / appliance HSM	PKCS#11 module to a network device	On the appliance; non-extractable	The appliance, its config, the operator
Cloud KMS	Managed-key provider (Pro)	In the cloud service; never returned	The cloud provider and its attestations
OpenSSL provider bridge	PKCS#11 via an OpenSSL bridge	On the token; non-extractable	The token and its operator

미니 FAQ

키가 PHP 프로세스에 들어가는 일이 있습니까? 없습니다. 추출 불가능한 PKCS#11 키의 경우, 개인 값은 토큰 밖에서 평문으로 드러날 수 없습니다. NextPDF는 토큰의 작업을 통해 서명하며, 서명할 바이트와 반환된 서명만을 봅니다.

HSM 기반 서명은 PDF 내부에서 다릅니까? 아닙니다. 서명 구조는 동일한 바이트 범위에 걸쳐 동일한 Contents 항목에 들어가는 동일한 CMS SignedData입니다. HSM은 서명이 일어나는 위치를 바꿀 뿐, 디스크상의 형태를 바꾸지 않습니다.

NextPDF를 통해 HSM을 사용했으니 FIPS 준수를 주장할 수 있습니까? 오직 신중하게만 가능합니다. NextPDF는 장치의 FIPS 상태에 대해 아무것도 주장하지 않습니다. 그러한 주장은 NextPDF가 장치를 호출했다는 사실이 아니라, 장치 자체의 검증과 그것이 배포되는 방식에서 나와야 합니다.

인프로세스 PKCS#11 바인딩을 사용할 수 없으면 어떻게 됩니까? 엔진은 조용히 소프트웨어 키로 폴백하는 대신 하드웨어 서명을 사용할 수 없다고 보고합니다. 인프로세스 바인딩이 토큰을 로드할 수 없는 배포를 위해 OpenSSL 명령줄 브리지 경로가 존재합니다.

관련 문서

• 적격 서명에 대한 설명 — 하드웨어 키가 무엇에 대해 필요하지만 충분하지는 않은지, 그리고 NextPDF가 아닌 역할들에 관한 설명입니다.
• 서명이 PDF 안에 자리하는 방식 — HSM 결과가 기록되는 바이트 범위와 서명 딕셔너리 메커니즘입니다.
• 프로덕션에서 NextPDF 운영하기 — 하드웨어 서명 배포가 떠안는 운영 표면입니다.

용어집

• HSM(하드웨어 보안 모듈) — 키를 보관하고 암호화 작업을 수행하여 키 재료가 결코 밖으로 나가지 않게 하는 강화된 장치입니다.
• PKCS#11 — OASIS 암호화 토큰 인터페이스 표준(과거 명칭 “Cryptoki”)입니다. NextPDF가 하드웨어 토큰과 통신하기 위해 사용하는 C 인터페이스입니다.
• 추출 불가능한 키 — 개인 값이 토큰 밖에서 평문으로 드러날 수 없는 PKCS#11 키 객체입니다(CKA_SENSITIVE 참 또는 CKA_EXTRACTABLE 거짓).
• 이음매 — NextPDF의 서명 제공자 경계입니다. 불투명한 바이트가 들어가고 서명 옥텟이 나옵니다. PDF와 CMS 지식은 그 위에 있고, 키는 그 뒤에 있습니다.
• CMS SignedData — PDF 안에서 서명과 인증서를 운반하는 암호화 메시지 구문 구조(RFC 5652)입니다.
• FIPS 140-3 / ISO/IEC 19790 — 네 가지 정성적 수준을 정의하는 암호화 모듈 보안 표준입니다. 호출하는 라이브러리가 아니라 장치와 그 검증의 속성입니다.