PP pki type

무언가에 서명하는 모든 프로토콜은 알고리즘을 지정해야 하며, 발신자가 제어하는 필드에서 이를 지정하는 것이 다운그레이드 공격의 시작입니다. BIP70은 세 가지 값을 제공했으며, 그중 하나는 사양서가 작성되기 수년 전부터 취약한 것으로 여겨졌습니다. 브라우저는 2017년 1월에 SHA-1 인증서 퇴출을 마쳤고, 이 결제 프로토콜은 업데이트를 한 번도 내놓지 않았습니다.

작동 방식

상태: 역사적입니다. PP pki type은 PaymentRequest의 2번 필드였고 기본값은 "none" 문자열이었으며, 2020년 6월 3일의 버전 0.20.0부터 Bitcoin Core에서 빠졌습니다.

세 가지 값이 정의되었고 네 번째 값은 등록된 적이 없습니다. 다만 사양서는 네 번째 값이 들어갈 자리를 남겨 두었습니다.

"none"은 서명되지 않은 요청을 뜻했습니다. 인증서 필드는 비어 있었고 서명 필드도 비어 있었으며, 지갑은 금액과 목적지는 표시할 수 있었지만 신원은 전혀 표시할 수 없었습니다. 실제로 유통된 대부분의 요청이 정확히 이러했습니다.

"x509+sha256"은 판매자가 서명 필드를 비운 채 메시지 전체를 직렬화하고, 그 결과를 SHA-256으로 해시하고, 첨부된 체인의 첫 번째 인증서에 해당하는 개인 키로 그 해시에 서명하는 것을 뜻했습니다.

"x509+sha1"은 SHA-256 대신 SHA-1을 사용한 같은 절차를 뜻했습니다.

취약한 선택지를 제공했다는 점이 흥미로운 부분입니다. 발신자가 지정한 알고리즘을 그대로 받아들이는 검증자는 자신이 여전히 허용하는 가장 나쁜 알고리즘만큼만 강합니다. 그래서 이후의 설계는 메시지에서 허용 집합을 읽어 내지 않고 검증하는 쪽에서 허용 집합을 고정합니다. SHA-1은 2013년에도 좋은 후보가 아니었습니다. 2005년에는 무차별 대입보다 빠른 충돌 공격이 발표되었고, NIST는 2013년 이후 새로운 디지털 서명 생성에 SHA-1을 허용하지 않았습니다. 인증 기관들은 2015년 말에 SHA-1 인증서 발급을 중단했고, Chrome 56은 2017년 1월에 해당 인증서 신뢰를 중단했으며, 한 달 뒤 완전한 공개 충돌이 발생했습니다.

확인할 수 있는 곳

비트코인 자체가 발신자가 서명 알고리즘을 지정하는 방식에 대한 반례를 제공하며, 이 점은 기억해 둘 만합니다.

비트코인 트랜잭션은 검증하는 쪽과 서명 알고리즘을 협상하지 않습니다. 사용되는 출력이 문제를 확정합니다. Taproot 이전 출력은 secp256k1에 대한 ECDSA로 검증되고, Taproot 키로 지급하는 출력은 BIP340에 따른 Schnorr로 검증됩니다. 이 규칙은 2021년 11월의 블록 709,632에서 활성화되었습니다. 지출자는 깨뜨리기 더 쉬운 것을 제안할 수 없습니다. 코인을 받을 때 선택이 이미 고정되었기 때문입니다.

이 차이는 인증서 기반 계층이 비트코인 위에서 왜 그렇게 어울리지 않았는지를 설명합니다. 합의 규칙은 모든 사람에게 동일하게 적용되고 조율된 업그레이드로만 바뀌는 반면, 알고리즘을 지정하는 필드는 협상이며, 협상은 다운그레이드됩니다.

소프트웨어를 작성하는 것이 아니라 어디에서 구매할지 고르는 중이라면, 유용한 버전은 좁지만 실질적입니다. 구식 암호화 선택지를 “호환성을 위해” 계속 살려 두는 플랫폼은 편의와 보안을 어떻게 저울질하는지 알려 주며, 그 판단은 직접 살펴볼 수 없는 시스템 부분에도 적용됩니다.

PP pki type vs SSL signature

PP pki type은 방식을 지정했고, SSL signature는 그것을 실행한 결과였습니다. 둘을 하나로 취급하면 오래된 BIP70 문서가 혼란스러워집니다. 요청이 유형을 지정하면서 서명을 전혀 담지 않을 수 있었고, 그것이 바로 "none"의 의미였기 때문입니다. 현대의 TLS는 알고리즘 식별자를 서명 바이트 옆에 기록하는 같은 짝을 유지하지만, 클라이언트는 한때 유효했던 모든 식별자를 더 이상 받아들이지 않습니다.