포괄적인 방법론은 결함 도메인을 분리하기 위해 서명 파이프라인과 검증 파이프라인을 분리하는 것으로 시작해야 합니다. 테스터는 OpenSSL 명령줄 도구를 사용하여 CMS(Cryptographic Message Syntax) 구조의 무결성을 확인해야 하며, 이는 PDF 뷰어와 독립적이어야 합니다. 시각적 회귀 테스트는 서명 외관 위젯을 Adobe Acrobat, Firefox PDF.js, Chrome PDFium, 모바일 iOS PDFKit 렌더러 간에 캡처하여 좌표 시스템의 오해를 감지해야 합니다. 시간 검증은 시스템 시계를 조작하여 인증서 만료 날짜 이후의 날짜로 설정하여 PAdES-LTV 체인이 내장된 OCSP 응답 및 TSA 토큰을 통해 유효성을 유지하는지를 검증합니다.
법률 기술 회사에서 eIDAS-인증된 신뢰 서비스 제공업체로부터 ECDSA P-256 인증서를 사용하는 계약 실행 플랫폼을 배포했습니다. 중대한 결함은 macOS에서 서명된 문서가 Preview 및 Adobe Acrobat에서는 유효한 서명을 표시했지만, Chrome의 네이티브 PDF.js 뷰어가 "서명 유효성 알 수 없음"을 보고했습니다. 이는 파일 구조에 내장된 OCSP 응답이 존재함에도 불구하고 발생했습니다.
우리는 세 가지 독립적인 수정 접근법을 평가했습니다. 첫 번째 접근법은 구식 PDF 파서와의 호환성을 높이기 위해 RSA 2048 암호화 키로 마이그레이션하는 것이었으며, 이로 인해 서명 바이트 크기가 약 40% 증가하고 성능이 제한된 모바일 장치에서 상당히 저하되었습니다. 두 번째 접근법은 문서 구조를 단순화하고 파싱 복잡성을 줄이기 위해 LTV 내장을 비활성화하는 것이었지만, 이로 인해 인증서 만료 후 서명이 무효가 되어 법률 문서의 10년 유지 의무를 위반하게 됩니다. 세 번째 접근법은 DSS(Document Security Store) 사전을 재구성하여 ByteRange 참조 앞에 OCSP 응답 배열을 배치하여 PDF.js의 선형 파싱 요구 사항을 수용하는 것이었으며, 이는 파일 크기를 증가시키지 않으면서 내구성을 저하시키지 않았습니다. 이 접근법은 복잡한 저수준 PDF 객체 조작이 필요했습니다.
우리는 세 번째 솔루션을 선택했습니다. 이유는 PDF.js가 선형 파싱 순서 요구 사항을 엄격히 시행하는 반면, Adobe Acrobat는 보다 허용적인 랜덤 접근 파싱 모델을 사용하기 때문입니다. 이 구현은 플랫폼 간 유효성 불일치를 해결하여 모든 대상 플랫폼에서 일관된 "서명 유효" 지표를 달성하였으며, 엄격한 PDF/A-3 준수 및 장기 보관 규정을 위한 PAdES-LTV 내구성을 유지했습니다.
PDF/A 준수 수준이 디지털 서명 가시성 및 검증 메커니즘에 미치는 영향은 무엇인가?
많은 테스터가 PDF/A 준수를 이진 상태로 오해하기 보다는 단계적 사양으로 간주해야 합니다. PDF/A-1b는 시각적 재현성만 보장하지만, PDF/A-2a는 태그 구조와 Unicode 문자 맵을 요구합니다. 서명 생성 시, 외관 스트림은 문서의 DA(Default Appearance) 문자열 내에 내장된 글꼴을 사용해야 합니다. 만약 서명 서비스가 원본 문서의 글꼴 부분집합에 존재하지 않는 시스템 글꼴을 주입하면, 서명 암호화가 수학적으로 유효하더라도 PDF/A 검증이 서명 후에 실패합니다. 테스터는 서명 위젯 생성 중 글꼴 부분집합이 발생하는지 확인하고, /DR(Default Resources) 사전이 시스템 글꼴 이름이 아닌 이전에 내장된 글꼴 스트림만 참조하는지 검증해야 합니다.
왜 내장된 OCSP 응답이 암호적으로 올바르더라도 LTV(장기 유효성) 상태를 수립하지 못하는가?
후보자들은 종종 DSS 사전 내에 OCSP 응답 바이트가 존재하는지를 확인할 뿐 유효성 검사 체인의 완전성을 체크하지 않습니다. LTV 설립에는 OCSP 응답자 인증서, 타임스탬프 토큰 및 타임스탬프 기관 인증서를 포함한 완전한 신뢰 앵커 체인이 필요합니다. 만약 OCSP 응답이 자신의 폐기 검사가 필요한 인증서로 서명되었고, Certs 배열 내에 응답자를 위한 내장된 OCSP 응답이 없다면, Adobe Acrobat은 LTV 모드를 활성화하는 것을 거부합니다. 테스터는 DSS 내의 Certs 배열에 루트 CA를 제외한 모든 중간 인증서가 포함되어 있는지, 각 타임스탬프가 서명과 OCSP 응답을 모두 포함하고 있는지를 검증해야 하여 PAdES-T 수준 준수 최소 요건을 충족해야 합니다.
Adobe Acrobat과 모바일 PDF 뷰어 간 서명 외관의 불일치 원인은 무엇인가?
서명 위젯 위치를 정의하는 Rect(사각형) 배열은 서로 다른 뷰어가 다르게 해석하는 페이지 좌표 시스템을 사용합니다. Adobe Acrobat은 좌표를 하단 왼쪽 원점(표준 PDF 좌표 공간)에서 계산하는 반면, iOS PDFKit과 같은 일부 모바일 뷰어는 Rotate 항목이 존재할 경우 상단 왼쪽 원점에서 CropBox 계산을 적용합니다. 서명 위젯이 음수 좌표를 갖거나 MediaBox 경계를 초과하면 데스크탑 뷰어가 모바일 구현과 다르게 표시될 수 있습니다. 테스터는 좌표를 CropBox 및 ArtBox 경계와 검증하고 페이지 사전의 Rotation 항목이 외관 XObject에 대해 변환 행렬을 적용하는지 확인해야 합니다.