C2PA Assertion Hashed URI: 누락과 해시 불일치를 검토하는 방법
파일과 검증기 전체 출력을 보존합니다
C2PA 호환 검증기로 열기 전에 실제 파일을 그대로 저장합니다. 출처 URL 또는 로컬 경로, 파일명, 입수 시각, 검증기 이름과 버전을 기록하고 전체 출력을 파일과 함께 보관합니다. 이 표 형식은 재현 가능한 검토를 위한 본문의 제안이며 C2PA가 요구하는 서식은 아닙니다.
질문을 먼저 제한합니다. 이 claim의 각 assertion reference가 같은 C2PA Manifest 안에서 해석되는지, 그리고 assertion data가 claim에 기록된 hash와 일치하는지를 확인합니다. 이는 provenance record의 내부 무결성 질문입니다. Caption, 화자, 장소, 촬영 시각이나 화면 속 사건의 정확성을 확정하지 않습니다.
Claim과 assertion마다 로컬 식별자를 붙이고 label과 status code를 그대로 복사합니다. 단일 색상 badge나 pass/fail 제목만 남기면 missing reference, outside-manifest reference, 잘못된 data 형식, hash mismatch를 구분할 수 없습니다.
Hash를 비교하기 전에 URI를 하나씩 해석합니다
C2PA 2.2에서 claim의 created_assertions와 gathered_assertions 항목은 hashed_uri 구조입니다. Version 1 claim은 assertions 필드를 사용합니다. 다른 곳에서 gathered된 assertion도 claim의 일부이므로 같은 validation algorithm을 거칩니다. 일부만 뽑지 말고 항목마다 확인합니다.
먼저 URI가 redacted assertion 목록에 있는지 봅니다. Claim은 자기 manifest의 assertion을 redact할 수 없습니다. Redacted되지 않은 assertion은 url 필드를 해석해 실제 위치를 기록합니다. Reference는 같은 C2PA Manifest 내부의 self#jumbf 위치여야 합니다. Manifest 바깥을 가리키면 assertion.outsideManifest, URI를 해석하고 data를 가져올 수 없으면 assertion.missing입니다.
두 결과를 합치지 않습니다. assertion.outsideManifest는 허용된 manifest 경계를 벗어난 reference이고, assertion.missing은 referenced data를 해석하고 가져오지 못한 결과입니다. 어느 code도 파일을 누가 왜 바꿨는지 설명하지 않습니다.
Assertion store에는 있지만 claim의 assertion array에서 참조되지 않은 항목도 따로 기록합니다. C2PA는 이 상태에 assertion.undeclared를 사용합니다. Claim이 선언한 것처럼 임의로 기록에 포함하지 않습니다.
Algorithm을 확인하고 JUMBF hash를 비교합니다
URI가 해석되면 specification의 algorithm determination 절차를 따릅니다. 검증기가 사용한 algorithm과 반환한 failure code를 기록합니다. 이어서 C2PA가 인용한 JUMBF box hashing 절차로 assertion hash를 계산하고 hashed_uri의 hash 값과 비교합니다.
불일치는 assertion.hashedURI.mismatch, 일치는 assertion.hashedURI.match로 기록됩니다. 대소문자를 포함한 code, assertion label, resolved URI, algorithm과 도구가 표시한 digest 정보를 보존합니다. 도구가 필드를 숨기면 표시되지 않았다고 쓰고 성공 badge에서 추정하지 않습니다.
Hash match는 선택한 algorithm으로 계산한 assertion data와 claim의 기록값이 일치한다는 좁은 질문에 답합니다. Assertion 안의 모든 서술이 현실적으로 맞다는 뜻은 아닙니다. Mismatch도 미디어가 합성이거나 화면 속 사건이 거짓이라는 증거가 아닙니다.
Data 형식 오류를 별도 단계로 기록합니다
C2PA는 reference와 hash 처리 뒤에도 검사를 수행합니다. Standard assertion이 well-formed CBOR가 아니면 assertion.cbor.invalid, JSON이 규격에 맞지 않으면 assertion.json.invalid가 됩니다. 이 code는 assertion.missing이나 hash mismatch와 다른 validation stage를 설명하므로 별도 칸에 둡니다.
검토표는 assertion마다 한 행을 만들고 claim 식별자, array 이름, assertion label, URI, redaction 여부, resolved location, algorithm, hash result, data-format result, 미해결 질문을 적습니다. 두 사본을 비교할 때는 각 파일의 표를 독립적으로 완성합니다. 빈칸은 그 실행에서 표시되거나 발견되지 않았다는 뜻이지 과거에도 없었다는 증거가 아닙니다.
결과가 불완전하면 파일을 보존하고 문서화한 다른 검증기 버전으로 다시 실행합니다. 가능하면 게시자가 보관한 원본이나 독립적으로 확보한 사본과 비교합니다. 관찰된 차이만 보고하고 C2PA code에서 동기, 작성자 또는 현실 원인을 만들어내지 않습니다.
Provenance 무결성, 탐지, 사실 확인을 분리합니다
저장한 파일을 DeepFakeCheck로 분석한다면 확률적 risk signal을 별도 구역에 둡니다. DeepFakeCheck는 C2PA assertion URI를 해석하거나 JUMBF hash를 검증하고 C2PA status code를 발행하는 도구가 아닙니다. 자동 탐지에는 진짜 자료를 의심하는 오탐과 합성 또는 변경 자료를 놓치는 미탐이 있습니다.
높은 risk는 추가 검토 이유이고 낮은 risk는 missing assertion을 복구하거나 파일을 인증하지 않습니다. assertion.hashedURI.match도 기록된 assertion integrity 결과만 뒷받침할 뿐 장면, caption, 화자, 게시 맥락을 확인하지 않습니다. 그런 주장은 원 게시물과 독립 자료로 따로 검증합니다.
마지막에는 정확한 파일, 검증기와 버전, assertion별 표, 전체 출력, 외부 자료, 사용했다면 detector output, 미해결 질문과 조치를 남깁니다. 다음 담당자가 기술적 무결성 결과를 사건 진위 판정으로 바꾸지 않고 URI와 hash 검사를 반복할 수 있어야 합니다.
출처
- C2PA, “C2PA Technical Specification — Validate the Assertions”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_validate_the_assertions