포스트-양자 서명이 조용히 도착합니다: .NET에서 Word 문서를 위한 ML-DSA

💡 전체 작업 예제가 GitHub에 있습니다:
sign-word-with-ml-dsa-certificates-dotnet

이전 방식은 프로젝트 계획이었습니다

문서 서명을 포스트-양자화로 만들기 위해 무엇이 필요한지 물어보면 로드맵이 나옵니다: 알고리즘 평가, 라이브러리 선택, 서명 코드 위에 추상화 레이어 작성, 이중 서명 기간 계획, 분기 예산 책정.

대부분은 조직적인 측면—인증서 조달, 정책, 검증기 지원—에 아직도 해당됩니다. 코드 측면은 로드맵이 암시하는 것보다 작았으며, 이는 누군가가 분기 예산을 잡기 전에 알아두면 좋은 정보입니다.

ML-DSA 서명은 .NET용 GroupDocs.Signature 기능으로, FIPS 204 기반 NIST 포스트‑양자 서명 표준 인증서를 사용해 Word 문서를 서명합니다. 26.9에 도입되었으며, 호출 코드 입장에서는 다른 PFX 파일과 동일합니다.

더 나은 방법이 있습니다

전체 코드 변경 내용은 다음과 같습니다:

using var signature = new Signature(sourcePath);

var options = new DigitalSignOptions(pfxPath)
{
    Password = certificatePassword
};

SignResult result = signature.Sign(outputPath, options);

이는 RSA 인증서에 사용되는 호출과 동일합니다. 알고리즘은 인증서의 속성이므로 옵션으로 선택할 필요가 없고, 추상화 레이어도 필요 없으며, 전환 기간을 위한 두 번째 코드 경로도 나타나지 않습니다. DigitalSignOptions에 ML‑DSA PFX를 지정하면 출력은 ML‑DSA 서명이 됩니다.

여러 인증서를 동시에 사용할 때 결과에서 인증서를 다시 읽어오는 것이 유용합니다:

var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";

의견 대신 숫자로 레벨 선택하기

ML‑DSA는 세 가지 파라미터 세트를 제공하며, 이는 NIST 보안 카테고리 2, 3, 5에 매핑됩니다. 강력할수록 키와 서명이 커집니다—가장 합리적인 방법은 문서를 세 번 서명해 보고 비교하는 것입니다:

var levels = new Dictionary<string, string>
{
    ["ML-DSA-44"] = MlDsa44Pfx,
    ["ML-DSA-65"] = MlDsa65Pfx,
    ["ML-DSA-87"] = MlDsa87Pfx
};

샘플은 레벨당 하나의 서명된 복사본을 만들고 각 크기를 기록하므로, 트레이드‑오프는 사양 표가 아니라 측정값이 됩니다. 단일 계약에서는 차이가 눈에 띄지 않지만, 수백만 개의 서명된 문서가 있는 아카이브에서는 최고 레벨을 표준화하기 전에 용량 문제를 고민해야 합니다.

정책이 지정하지 않은 경우 ML‑DSA‑65가 합리적인 기본값입니다. CNSA 2.0 같은 프로파일은 ML‑DSA‑87을 명시하고, 크기가 마진보다 중요한 경우에만 ML‑DSA‑44가 의미가 있습니다.

검증에는 공개 인증서만 필요합니다

배포 방식은 RSA와 동일하게 유지되며, 이는 두 번째 좋은 소식입니다:

var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
    options.Password = password;
}

VerificationResult result = signature.Verify(options);

수신자는 서명자의 .cer 파일만 있으면 되며, 그 외는 필요 없습니다. 결과는 서명이 내용과 일치하고 인증서가 일련 번호와 지문으로 일치할 때만 유효하므로, 다른 당사자가 서명한 문서는 검증에 실패합니다—샘플은 올바른 인증서와 다른 사람의 인증서를 각각 사용해 검증을 두 번 실행함으로써 이를 증명합니다.

나란히 보기: 예상 vs 실제

마지막 행이 계획을 제약하는 요소이며, 이 글의 솔직한 부분으로 이어집니다.

아직 작동하지 않는 부분

두 가지 제한 사항이 있으며, 약속하기 전에 반드시 알아두어야 합니다.

• 포맷 지원은 26.9에서 Word만 지원합니다—DOCX, DOC, ODT 및 Word 계열 전체. PDF, 스프레드시트, 프레젠테이션은 ML‑DSA로 서명할 수 없습니다. PDF‑우선 파이프라인이라면 이번 릴리스는 프로토타이핑 및 측정용이며 마이그레이션용은 아닙니다.
• 검증기 지원도 문제입니다. 아직 ML‑DSA에 대한 표준 XML‑DSig 식별자가 없으므로 Microsoft Word는 서명이 유효하더라도 이를 “유효함”으로 표시하지 않을 수 있습니다. 이는 결함이 아니라 표준 격차이며, 검증은 파일을 열어 배너를 확인하는 리뷰어가 아니라 여러분의 코드에서 수행되어야 함을 의미합니다.

또한 플랫폼 세부 사항 중 행동이 필요 없는 부분이 있습니다: .NET은 Linux(.NET 8 포함)에서 ML‑DSA 키를 읽을 수 없습니다. 읽을 수 없는 경우 GroupDocs.Signature는 Word 엔진을 통해 인증서를 읽으므로, 동일한 빌드가 개발자 노트북과 Linux 컨테이너 모두에서 조건부 코드 없이 실행됩니다.

이러한 제한을 감안했을 때 지금 바로 진행할 가치가 있나요?

네, 코드와는 무관한 두 가지 이유가 있습니다. 인증서 조달은 느리며—공개 CA가 아직 ML‑DSA 발급을 확대 중이기 때문에—조직 측 작업은 일찍 시작할수록 이점이 있습니다. 그리고 “오늘 포스트‑양자 서명을 만들 수 있는가”는 컴플라이언스 팀이 점점 더 묻는 질문이며, 계획이 아닌 서명된 문서로 답할 수 있다는 점은 몇 시간 투자만으로도 충분히 가치가 있습니다.

샘플이 실제로 증명하는 것

네 가지 메서드를 순서대로 실행하고 종료 코드를 결과에 연결합니다. 계약서를 ML‑DSA‑65로 서명하고 사용된 인증서의 주체를 출력합니다. 같은 계약서를 세 레벨 모두에서 서명하고 결과 크기를 출력합니다. 서명된 파일을 두 번 검증합니다—한 번은 서명자의 공개 인증서로 성공을 기대하고, 한 번은 다른 서명자의 인증서로 실패를 기대합니다. 마지막으로 출력 파일에 포함된 디지털 서명을 나열합니다.

두 번째 검증이 복사할 가치가 있는 부분입니다. 한 번도 유효한 입력만 보여준 루틴은 잘못된 입력을 거부할지에 대해 아무것도 알려주지 않으며, 서명 검증에서는 이것이 전부입니다.

실제 사례: 30년 계약

장기 보관 아카이브는 이론을 넘어서는 곳입니다. 오늘 서명하고 30년 동안 보관해야 하는 계약서는 그 기간 동안 암호학이 어떻게 변하든 검증 가능해야 하며, “지금 수집하고 나중에 복호화”는 바로 그런 자료에 대한 문서화된 위협 모델입니다.

이러한 아카이브에 대해 실용적인 오늘의 조치는 이중 트랙입니다: 아직 ML‑DSA가 지원하지 않는 포맷은 RSA를 유지하고, Word 출력은 ML‑DSA‑65 또는 87로 서명하며, 문서마다 사용된 알고리즘을 기록해 향후 감사를 위해 파일을 열지 않고도 구분할 수 있게 합니다.

샘플을 복사하기 전에 수정해야 할 한 가지

리포지토리는 자체 서명된 ML‑DSA 인증서를 포함하고 있어 데모를 바로 실행할 수 있습니다. 즉, documents/에 네 개의 PFX 파일과 하드코딩된 비밀번호가 들어 있습니다. 샘플 내부에서만 유효한 일회용 테스트 인증서라면 괜찮습니다.

하지만 이것을 여러분의 리포지토리로 그대로 가져가는 패턴은 권장되지 않습니다. 테스트 인증서를 실행 시에 생성하거나, GroupDocs의 certificate-validity 샘플처럼 처리하거나, 버전 관리에서 완전히 제외하십시오. 커밋된 키는 폐기하기 번거롭고, 데모가 끝난 뒤에도 남아 있을 위험이 있습니다.

결론

포스트‑양자 마이그레이션에서 가장 비용이 많이 드는 부분은 인증서, 정책, 검증기입니다. 코드 측면에서는 Word 문서에 대해 .NET에서 다른 PFX와 동일한 DigitalSignOptions 호출만 있으면 됩니다. 샘플을 복제하고 자체 계약서에 적용하면 몇 분 안에 서명된 파일 3개, 검증 결과 2개, 크기 비교를 얻을 수 있으며, 이는 추정치보다 훨씬 실질적인 마이그레이션 계획 기반이 됩니다.

추가 자료

• GitHub의 전체 .NET 샘플 프로젝트
• 단계별 사용 사례 가이드
• 디지털 서명으로 문서 서명하기
• 문서 내 디지털 서명 검증하기
• GroupDocs.Signature for .NET 문서
• Free support forum