요약

  • RFC 3075는 직관적으로 떠올릴 수 있는 “문서”에 서명하지 않았다. 이 표준은 정규화된SignedInfo에 서명했으며, 그 안의Reference항목들은 순서화된 변환 체인을 거친 후 선택된 데이터의 다이제스트에 확약했다.
  • 핵심 검증은 서명되지 않은 소스 노드, 변경될 수 있는 외부 스타일시트, 묶이지 않은KeyInfo, 검증되지 않은 Manifest 구성원 또는 애플리케이션 신뢰가 그 영수증 밖에 남은 상태에서 성공할 수 있었다.

책상 위의 파일은 하나의 문서처럼 보였다. 그러나 서명 엔진은 경계들의 연쇄를 보고 있었다.

먼저 URI로 식별되거나 애플리케이션 맥락에서 공급되는 리소스가 있었다. 그 다음은 0개 이상의 변환이었다. XPath는 부분집합을 선택할 수 있었다. XSLT는 다른 표현을 구성할 수 있었다. Base64 디코딩은 눈에 보이는 문자를 전혀 다른 입력 바이트로 바꿀 수 있었다. 정규화(canonicalization)는 XML 노드 집합을 반복 가능한 옥텟 스트림으로 직렬화할 수 있었다. 그 연산들이 끝난 후에야 다이제스트가Reference에 들어갔다. 참조, 메서드, 다이제스트 값은SignedInfo로 들어갔다. 두 번째 정규화가SignedInfo를SignatureValue서명에 맞게 준비시켰다.

2001년 3월 XMLDSIG 워킹 그룹이 발행한 RFC 3075는 이 체인을 상호운용 가능한 구문과 처리 모델로 만들었다. 이 표준은 XML 또는 비 XML 데이터, 서명 안에 감싸진(enveloping) 콘텐츠, 서명 주변에 감싸진(enveloped) 콘텐츠, 그 밖의 장소에 있는 분리(detached) 리소스를 모두 다룰 수 있었다. 이러한 유연성 덕분에 디지털 서명이 웹에서 유용해졌다. 동시에 성공적인 결과의 범위가 “문서에 서명되었다”는 사람의 표현보다 좁아졌다.

두 검증이 하나의 핵심 결과를 만들었다

RFC는 핵심 검증(core validation)이 서로 다른 두 가지 작업을 하도록 요구했다. 참조 검증(reference validation)은SignedInfo의 모든Reference에 대해 데이터 객체를 획득하고, 다이제스트 입력을 만들고, 지정된 다이제스트를 계산해DigestValue와 비교했다. 서명 검증(signature validation)은 키를 획득해 정규화된SignedInfo위의SignatureValue를 지정된 서명 메서드로 확인했다.

어느 한쪽이 다른 쪽을 대신할 수 없었다.SignedInfo에 대한 올바른 서명은 나쁜 참조 다이제스트를 치유하지 못했다. 일치하는 참조 다이제스트가SignedInfo를 인증하지도 않았다. 둘 다 통과했을 때, 그 결과는 하나의 키를 특정한 다이제스트 확약 집합과 처리 식별자들에 결합했다. 그 결과는 서명 근처의 모든 노드, 뷰어가 연 모든 리소스, 애플리케이션이 부여하는 모든 의미로 자기 자신을 확장하지 않았다.

이 구분은 RFC 3075를 봉인된 파일에 관한 더 단순한 이야기와 분리시킨다.SignedInfo가 서명된 제어 표면이었다. 데이터 객체들은 참조 다이제스트를 통해 간접적으로 묶였다. 따라서 결과를 조사하는 운영자에게는 최소한 두 개의 영수증이 필요했다. 서명 알고리즘이 확인한 정확한 정규화된SignedInfo, 그리고 각 다이제스트가 확인한 정확한 변환 후 바이트.

변환이 서명된 객체를 결정했다

각Reference는 리소스를 식별하고 순서화된 변환 목록을 함께 담을 수 있었다. 서명자는 XPath를 사용해 편집 가능하게 두려는 필드를 제외하거나, 계산 대상에서 감싼 서명을 제거하거나, 인코딩된 객체를 디코딩하거나, 다이제스트 앞에 XSLT를 적용할 수 있었다. RFC는 그 결과를 명확히 밝혔다. 변환이 폐기한 정보는 서명에 의해 보호되지 않는다.

그것이 자동으로 결함은 아니었다. 재사용 가능한 양식은 지정된 입력 영역을 열어 두면서 고정된 조항을 의도적으로 보호할 수 있었다. 분리 서명은 XML 안에 표현된 래퍼 태그가 아닌 디코딩된 바이너리를 대상으로 할 수 있었다. 서명자와 검증자가 그 경계에 합의하고 애플리케이션이 의도된 형태를 강제한다면, 경계는 기능이었다.

위험은 사용자, 검토자 또는 비즈니스 규칙이 변환이 소스 트리 전체를 선택했다고 취급할 때 시작되었다. 제외된 금액, 목적지, 지시 또는 스타일 리소스는 선택된 다이제스트 입력이 동일하게 유지되는 동안 바뀔 수 있었다. 서명은 자신에게 요구된 객체를 정확하게 검증했다. 그 주변의 주장이 틀렸을 뿐이다.

RFC 3075는 지나치기 쉬운 한 가지 단서를 추가했다. 핵심 검증이 반드시 검증자가 URI를 새로 역참조하고 각 변환 단계를 실행했음을 증명하지는 않았다. 애플리케이션은 이미 변환된 데이터의 캐시 복사본을 받아들여 다이제스트를 검증할 수 있었다. 다른 애플리케이션은 새로운 획득과 실행을 요구할 수 있었다. 두 정책 모두 단순한 동등성 검사 바깥에 있었다. 따라서 완전한 감사는 선언된 파이프라인뿐 아니라 실제 다이제스트 입력이 어떻게 획득되었는지도 기록해야 했다.

정규 형식은 변형을 제거했지, 의미를 제거하지 않았다

디지털 서명은 검증자가 서명자와 같은 비트를 대상으로 계산해야 한다. XML은 이 요구를 어렵게 만들었다. 파서는 줄바꿈과 속성을 정규화하고, 엔티티를 확장하고, 네임스페이스를 매핑하며, 속성 순서 같은 표면적 선택을 폐기할 수 있기 때문이다. DOM과 SAX는 원본 바이트 스트림이 아니라 구조화된 정보를 노출한다.

정규화는 관련 노드 집합의 안정적인 직렬화를 제공했다. 허용되는 구문적 변형에도 불구하고 두 계산을 비교 가능하게 만들었다. 그러나 정규화는 두 표현이 같은 의미를 갖는지, 스키마가 진짜인지, 네임스페이스가 애플리케이션의 가정을 기술하는지, 또는 생략된 노드가 무해한지를 증명하지 않았다.

나중에 나온 Canonical XML 1.1 명세는 이 경계를 다른 방식으로 밝혔다. 정규 형식은 정의된 표현 차이를 다루지만, 애플리케이션 고유의 동등성은 일반적인 XML 정규화기의 범위 밖에 남는다는 것이다. 반복 가능한 바이트는 필수적인 증거였다. 그것은 범용 의미 엔진이 아니었다.

서명자가 본 것이 서명된 것과 맞아야 했다

RFC 3075의 보안 절은 표현을 미적 문제로 남겨 두지 않았다. 서명이 사람 또는 자동화된 에이전트의 판단을 표현하기 위한 것이라면, 보호되는 재료는 그 행위자에게 제시된 내용과 근사해야 한다. 화면 이미지를 문자 그대로 서명할 수 있었지만, 그것은 소프트웨어가 처리하기 어려웠다. 대안은 데이터를 그 표현을 형성하는 필터, 스타일시트, 클라이언트 프로필 또는 기타 입력과 함께 서명하는 것이었다.

의존하는 쪽에는 상호 의무가 있었다. 변환된 서명 형식 위에서 작동해야 했지, 원본이나 중간 표현을 마음대로 다루면 안 되었다. 외부 스타일시트가 가장 명확한 예였다. 스타일시트가 문서가 보이는 방식을 바꾸면서 자체적으로 참조되고 서명되지 않았다면, 유효한 데이터 서명은 그 결과 뷰를 고정시키지 않았다.

이것은 모든 XML 서명이 사람의 동의를 대표한다는 선언이 아니었다. RFC는 범위의 관점에서 정반대를 말했다. XML Signature는 키를 참조된 옥텟과 연관시켰을 뿐, 그 키가 어떤 사람이나 기관과 어떻게 관련되는지, 그리고 서명된 데이터가 무엇을 의미하는지를 규범적으로 확립하지 않았다. 렌더링 요구사항과 합의 의미는 애플리케이션의 몫이었다.

KeyInfo는 키를 찾을 수 있었지만 신뢰를 묶지는 않았다

KeyInfo는 공개 키, 인증서 데이터, 이름, 검색 지시 또는 애플리케이션 정의 재료를 담을 수 있었다. 수신자가 맥락에서 이미 키를 알 수 있으므로 그것은 선택 사항이었다. 핵심 구조에서 그것은SignedInfo밖에 놓였다.

이 배치가 중요하다. 서명자가KeyInfo를 암호적으로 묶으려면Reference가 그것을 포함할 수 있었다. 그런 참조가 없다면, 주변의 키 설명을 바꾸어도SignatureValue가 바뀌지 않을 수 있었다. 설령 서명 검증이 파싱되었거나 외부에서 공급된 키 정보를 여전히 사용한다 해도 말이다.

KeyInfo의 바이트를 묶는 것만으로 신뢰 판단이 끝나지 않았다. 인증서는 무결하면서도 해당 작업에 수용 불가능할 수 있었다.KeyName은 충실하게 서명되면서도 하나의 시스템 내부에서만 의미를 가질 수 있었다. RFC 2807은 이미 워킹 그룹의 헌장을 한정했다. XML Signature 구문은 콘텐츠와 키를 연관시킬 뿐, 임의의 신뢰와 주장 의미는 애플리케이션이 공급해야 했다.

서명된 Manifest가 모든 객체의 영수증은 아니었다

RFC 3075는 애플리케이션이 더 유연한 실패 정책을 원할 때 유용한 참조 목록인Manifest도 제공했다.SignedInfo가 Manifest를 참조하면 핵심 검증은 Manifest 요소의 다이제스트를 확인했다. 그러나 어떤 내부 참조를 검증할지, 그리고 객체를 이용할 수 없거나 비교가 실패할 때 무엇을 할지는 애플리케이션이 결정했다.

따라서 외부 목록은 진실일 수 있으면서, 목록에 담긴 하나 이상의 리소스는 성공적인 검증 영수증을 결여할 수 있었다. “Manifest가 서명되었다”고 말하는 것과 “모든 Manifest 객체가 획득되고, 변환되고, 일치했다”고 말하는 것은 서로 다른 진술이었다. 검토자에게 필요한 것은 외부의 녹색 표시만이 아니라 구성원 단위의 결과였다.

이후의 실천은 실행 가능한 자유를 좁혔다

RFC 3275는 상호운용 경험 이후 2002년 3월 RFC 3075를 폐기하고 여러 구문 변경을 이루었다. 그러나 핵심 구조는 유지했다. 참조는 변환된 데이터를 선택하고,SignedInfo는 확약을 담고, 키 신뢰는 애플리케이션의 과제이며, 표현은 서명된 것과 일치해야 한다는 것이다.

이후의 W3C XML Signature 1.1과 모범 사례 지침은 운영 경계를 더 명시적으로 만들었다. 잠재적으로 위험한 참조 작업 전에SignedInfo를 인증하라. 검증 키에 대한 신뢰를 확립하라. XPath, XSLT, 검색 방법, 변환 횟수, 외부 URI 스킴을 제한하라. 참조가 애플리케이션이 실제 사용하려는 요소를 보호하는지 확인하라.

이 권고들은 특정 RFC 3075 배치가 익스플로잇을 당했다는 증거가 아니다. 그것들은 유연하고 실행 가능한 서명 기술이 암호학 주변의 정책을 요구하는 이유를 보여준다. 서명 엔진은 자신의 정확한 질문에 답하면서도 애플리케이션을 틀린 질문 앞에 둘 수 있다.

오래가는 영수증은 배지가 아니라 체인이었다

Lu Heng의 Running-Code Primarity는 이후의 렌즈를 제공한다. 알고리즘 식별자, 스키마에 맞는 Signature 요소 또는 라이브러리의 성공적인 반환은 운영적 증명의 끝이 아니다. 검증자는 그 반환 값을 산출한 바이트와 판단을 보존해야 한다. Reality Layers는 두 번째 렌즈를 더한다. “서명됨”이라는 상징적 진술은 그 계층들이 붕괴될 경우 변환된 객체, 렌더링된 경험, 하류 효과를 앞질러 나아갈 수 있다.

두 에세이 모두 RFC 3075의 일부가 아니며, 어느 쪽도 그 역사를 다시 쓸 권한을 주지 않는다. 두 에세이는 함께 표준 자체의 경고를 선명하게 해준다. 서명은 막연한 의례적 권위가 아니었다. 그것은 선택된 데이터 위에 놓인 유계 영수증이었다. 그 강함은 그 이상을 주장하기를 거부하는 데서 나왔다.

출처

Lu Heng은 RFC 3075, RFC 3275 또는 W3C 권고를 작성하거나 승인하지 않았다. 그의 에세이는 이후 공개된 분석 렌즈다.