파일을 공개하지 않고도 기밀을 개시하는 방법

파일을 공개하지 않고도 그 파일이 특정 시점에 존재했음을 증명할 수 있습니다.

봉인된 Label 309 레코드가 하는 일이 바로 이것입니다. 발신자는 평문을 해시하고, 파일을 암호화한 뒤, 증명 레코드를 Cardano에 게시합니다. 암호문은 콘텐츠 주소 지정 위치에 저장되며, 이를 복호화할 수 있는 키 보유자에게만 제공됩니다. 공개 블록체인은 특정 커밋먼트가 공개된 블록 타임까지 존재했음을 증명하고, 평문은 선택된 대상에게만 읽힐 수 있도록 유지됩니다.

이는 법무, 컴플라이언스, 보안, 저널리즘, 파트너, 내부 조사 업무에 잘 맞습니다. 타임라인은 중요하지만 문서를 공개 인터넷에 올려서는 안 되는 모든 상황에 적합합니다.

여기서 말하는 기밀 개시란 무엇입니까?

전 세계가 아니라 특정 대상에게만 증거를 공유한다는 뜻입니다.

그 대상은 변호사, 감사인, 규제 기관, 기자, 내부 조사 팀, 고객사의 보안 담당자, 이사회 위원회, 파트너일 수도 있고, 미래의 자기 자신일 수도 있습니다.

목표는 평문을 공개 블록체인이나 공개 웹사이트에 올리지 않으면서 그 증거가 특정 시점에 존재했음을 증명하는 것입니다. 봉인된 존재 증명은 정확히 이 형태, 즉 비공개 파일에 대한 공개 시점 클레임을 위해 설계되었습니다.

실제로 공개 체인에 올라가는 것은 무엇입니까?

증명 레코드는 공개됩니다. 평문은 공개되지 않습니다.

온체인 레코드에는 다음이 담길 수 있습니다.

평문 해시 — 이것이 시점에 대한 증명입니다;
Cardano 트랜잭션의 블록 타임;
래핑된 키 자료를 담은 암호화 봉투;
하나 이상의 콘텐츠 주소 지정 암호문 URI (ar:// 또는 ipfs://);
발신자가 서명을 선택한 경우의 선택적 서명;
한 번에 여러 파일을 개시하는 경우의 Merkle 루트.

레코드에는 다음이 의도적으로 담기지 않습니다.

평문 파일;
읽을 수 있는 수신자 목록;
수신자의 개인 키;
신원 시드(Identity Seed);
복호화된 증거.

분명하게 짚어둘 미묘한 점이 하나 있습니다. 수신자의 공개 키 또한 체인에 절대 나타나지 않습니다. 수신자는 레코드에 이름으로 적히지 않으며, 시험 복호화에 성공해야만 그 레코드가 자신의 것임을 알게 됩니다. 관찰자는 레코드가 봉인되어 있다는 사실을 알고, 그 평문 해시와 블록 타임을 보며, 래핑된 키 슬롯의 개수를 셀 수 있습니다. 하지만 슬롯은 게시 전에 안전한 무작위 순서로 뒤섞이므로, "주 수신자가 맨 앞"과 같은 정보조차 새어 나가지 않습니다. 개수는 몇 명인지를 알려줄 뿐, 결코 누구인지를 알려주지 않습니다.

암호문 자체는 URI를 가진 누구나 다운로드할 수 있습니다. 그러나 일치하는 키가 없으면 읽을 수 없는 상태로 남습니다.

수신자는 봉인된 레코드를 어떻게 엽니까?

수신자는 발신자에게 수신 주소를 공유하고, 발신자는 그 주소로 레코드를 봉인합니다.

수신 주소는 그저 공개 키입니다. 발신자는 파일의 암호화 키를 그 주소로 래핑합니다. 이후 수신자의 클라이언트는 공개 Label 309 레코드를 스캔하면서, 각 레코드의 암호화된 키 슬롯을 자신의 개인 수신 키로 열어보려 시도합니다. 이 모든 과정은 수신자의 기기에서 로컬로 이루어집니다. 어떤 레코드가 자신의 것인지에 관한 정보는 기기를 떠나지 않습니다.

슬롯이 열리면 클라이언트는 암호문을 가져와 복호화하고, 평문 해시를 다시 계산한 뒤, 그 해시를 온체인 커밋먼트와 대조합니다. 일치하면 두 가지가 한 번에 확인됩니다. 수신자가 진짜 파일을 가지고 있다는 것, 그리고 바로 그 파일이 기록된 블록 타임에 커밋된 파일이라는 것입니다.

수신자는 개인 키를 보유하므로, 여기서 검증은 "커밋먼트가 존재했다"에서 "이 특정 콘텐츠가 존재했다"로 넘어갑니다. 수신 주소를 공유하고 봉인된 레코드를 수신하는 발신자 측 절차에 관해서는 봉인된 레코드를 받는 방법을 참고하십시오.

암호화한 파일을 그냥 이메일로 보내면 안 됩니까?

이메일은 파일을 옮길 수는 있지만, 독립적으로 검증 가능한 내구성 있는 타임스탬프는 아닙니다.

메시지는 삭제되거나 변조되거나 분실될 수 있습니다. 첨부 파일은 제거되기도 합니다. 메일 서버는 폐기됩니다. 내보내기 형식은 지저분하고 몇 년이 지나면 진위를 확인하기 어렵습니다. 그 어느 것도 검증하는 측에 파일이 언제 존재했는지 증명할 방법을 주지 못합니다.

봉인된 Label 309 레코드는 사용자의 메일함이나 그 누구의 서버에도 의존하지 않는 공개 증명 앵커를 파일에 부여합니다. 암호화된 페이로드는 별도로 보존할 수 있으며, 수신자는 나중에 복호화된 콘텐츠가 공개 체인에 커밋된 해시와 일치함을 증명할 수 있습니다. 수신자에게 이메일로 알림을 보내는 것은 여전히 가능합니다. 다만 증명이 그 이메일에 의존하지 않도록 하십시오.

암호화한 파일을 그냥 비공개 스토리지에 올리면 안 됩니까?

올릴 수 있고, 대개 그렇게 해야 합니다. 그러나 비공개 스토리지만으로는 공개 시점 앵커를 얻을 수 없습니다.

회사 스토리지 버킷, 사건 관리 도구, 보안 포털은 암호화된 파일을 완벽하게 보관할 수 있습니다. 다만 그중 어느 것도 스스로 답하지 못하는 질문이 있습니다. 나중에 검증하는 측이 그 암호화 패키지가 언제 존재했는지, 그리고 복호화된 평문이 공개 커밋먼트와 일치하는지를 증명할 수 있느냐는 것입니다. 그것이 없다면 "우리는 3월에 이 파일을 가지고 있었다"는 증거가 아니라 단순한 주장일 뿐입니다.

Label 309는 타임스탬프가 찍힌 커밋먼트를 더해줍니다. 이는 기존 보안 스토리지를 대체하지 않습니다. 오히려 그 스토리지 위에 검증 가능한 증명 계층을 얹어줍니다.

개시 레코드는 언제 서명해야 합니까?

익명성보다 책임 소재가 더 중요할 때 서명하십시오.

레코드 서명은 선택 사항입니다. 서명은 특정 신원 키가 그 개시를 보증하게 해줍니다. 회사가 감사인에게 공식 증거 패키지를 보낼 때, 또는 법무 팀이 책임 소재가 분명하고 귀속 가능한 레코드를 필요로 할 때 유용합니다. 이 서명은 공개 키로 뒷받침되는 작성자 클레임이며, 검증하는 측은 어떤 서버도 신뢰하지 않고 이를 검증할 수 있습니다.

발신자의 익명성이 더 중요하다면 레코드를 서명하지 않은 채로 두십시오. 서명되지 않은 봉인 레코드는 체인에 발신자 신원을 전혀 결속하지 않으며, 이는 내부고발 제보나 봉인 입찰 시나리오에 정확히 필요한 속성입니다. 이 절충은 의도적인 선택이어야 합니다. 서명은 누가 그 개시 뒤에 있었는지를 확립할 수 있지만, 민감한 맥락에서는 바로 그 귀속이 발신자가 원하는 것보다 더 많은 정보를 드러낼 수 있습니다.

하나의 레코드로 여러 수신자에게 전달할 수 있습니까?

가능합니다. 단일 봉인 레코드는 파일의 암호화 키를 여러 수신자를 위한 별도 슬롯으로 래핑할 수 있습니다.

각 수신자는 자신의 키로 레코드를 열며, 한 수신자가 자기 슬롯을 이용해 다른 수신자의 키를 도출할 수는 없습니다. 이는 법무법인과 그 의뢰인, 내부 조사 팀, 감사인과 회사 담당자, 동시에 여러 규제 기관, 이사회 위원회를 모두 포괄합니다. 또는 다른 사람들과 공유하면서 자신을 위해 복구 가능한 사본을 보관하는 발신자도 포괄합니다.

공개 레코드는 슬롯의 개수를 드러낼 수는 있어도, 그 슬롯이 누구의 것인지를 읽을 수 있는 목록으로는 결코 드러내지 않습니다.

파일이 많은 대규모 증거 패키지는 어떻게 합니까?

파일마다 트랜잭션을 하나씩 만드는 대신, 매니페스트와 Merkle 배칭을 사용하십시오.

각 파일을 해시해 리프로 만들고, 리프들을 하나의 Merkle 루트로 접어 넣은 뒤, 그 단일 루트를 Label 309 레코드에 게시합니다. 매니페스트와 보조 파일은 필요에 따라 봉인합니다. 이후 수신자나 감사인은 전체 패키지를 불투명한 아카이브로 다루는 대신, 간결한 포함 증명으로 개별 파일을 — 전적으로 오프라인에서 — 검증할 수 있습니다. 포함 증명의 크기는 배치 크기의 로그에 비례해서만 커지므로, 파일이 천 개인 개시도 여전히 항목별로 검증됩니다.

이는 수천 개의 파일을 하나의 레코드로에서 설명한 것과 동일한, 여러 파일에 루트 하나를 쓰는 패턴입니다. 여기서는 이 패턴이 대규모 개시를 전부 아니면 전무가 아니라 들여다볼 수 있게 만들어 줍니다.

봉인된 레코드는 실제로 무엇을 증명합니까?

클레임은 강력하지만, 구체적입니다. 봉인된 Label 309 레코드는 다음을 보여줄 수 있습니다.

그 정확한 데이터가 공개된 블록 타임까지 존재했다는 것;
복호화된 암호문이 커밋된 평문 해시와 일치한다는 것;
레코드가 서명되어 있다면, 특정 키가 그 레코드에 서명했다는 것;
특정 파일이 Merkle로 배칭된 증거 집합에 포함되어 있었다는 것;
키와 암호문을 보유한 수신자가 복호화 가능한 증거에 접근할 수 있었다는 것.

이 각각은 시점과 무결성에 관한 정확하고 독립적으로 점검 가능한 진술입니다.

무엇을 증명하지는 않습니까?

그에 못지않게 중요한, 이 레코드가 확립하지 않는 것은 다음과 같습니다.

증거가 진실임을 증명하지는 않습니다. 증명은 바이트와 시점을 보증할 뿐, 사실을 보증하지 않습니다.
발신자가 그 파일을 개시할 법적 권리를 가졌음을 증명하지는 않습니다.
수신 주소가 신뢰할 수 있는 절차로 확인되지 않은 한, 수신자의 현실 세계 신원을 증명하지는 않습니다. 주소를 실제로 누가 소유하는지 확인하는 것은 별개의 단계입니다 — 파일을 봉인하기 전에 수신자를 확인하기를 참고하십시오.
익명성을 제공하지는 않습니다. 시점 패턴, 네트워크 메타데이터, 게이트웨이와 결제 흔적, 기기 핑거프린트, 운영상의 실수는 모두 레코드 밖에 존재하는 정보를 드러낼 수 있습니다. 또한 수신자는 평문을 복호화한 뒤 이를 유출할 수도 있습니다.
법률 자문이나 안전한 개시 절차를 대체하지는 않으며, 특정 증명이 분쟁에서 도움이 되는지는 관할권에 따라 달라집니다.

이 경계에 대한 일반적인 설명은 증명이 증명하지 않는 것을 참고하십시오.

팀은 필요해지기 전에 이를 어떻게 준비해 두어야 합니까?

위기가 닥쳤을 때가 아니라 그 전에 개시 워크플로를 정의하십시오. 다음을 미리 결정하십시오.

누가 봉인된 개시를 생성할 수 있는지;
공식 레코드에 서명하는 신원이 있다면 어느 신원인지;
어떤 수신 주소가 신뢰되는지, 그리고 그것이 어떻게 확인되었는지;
암호문이 어디에 저장되는지;
누가 복호화할 수 있는지;
다중 파일 패키지를 위해 매니페스트를 어떻게 구성하는지;
트랜잭션 참조를 어떻게 기록하고 인계하는지;
법률 검토를 위해 증거를 어떻게 내보내는지.

암호 기술은 한 겹의 계층일 뿐입니다. 압박이 닥쳤을 때 그 증명이 실제로 쓸모 있는지를 결정하는 것은 이를 둘러싼 절차입니다. 증거 처리 관점에 대해서는 법적 증거와 전자증거개시를, 그리고 위험도가 더 높은 출처에 대해서는 내부고발 증거를 참고하십시오.

요약

기밀 개시에는 프라이버시와 증명, 이 두 가지가 동시에 필요합니다.

봉인된 Label 309 레코드는 선택된 키 보유자를 위해 파일을 암호화된 상태로 유지하면서, 그 해시에 대한 공개적이고 타임스탬프가 찍힌 커밋먼트를 게시합니다. 수신자는 로컬에서 복호화하고 평문이 온체인 해시와 일치함을 확인합니다. 서명, Merkle 루트, 다중 수신자 슬롯은 필요할 때 더 강력한 워크플로 옵션을 더해줍니다.

이를 활용해 파일을 끝내 공개하지 않으면서도 타임라인을 증명하십시오.

더 읽어보기

Label 309 — 봉인된 레코드를 뒷받침하는, 개방적이고 벤더 중립적인 존재 증명 표준입니다. Label 309는 온체인 메타데이터 레이블이며, 이 제안은 Metadata 카테고리 CIP로서 Cardano CIP 프로세스에서 검토 중입니다 (공개 PR).
CardanoWall 오픈 소스 — 표준 코퍼스, SDK, 그리고 레코드를 빌드하고 봉인하고 검증할 수 있는 cardanowall 명령줄 도구입니다.
증명이 증명하지 않는 것 — 모든 존재 증명의 한계입니다.
파일을 봉인하기 전에 수신자를 확인하기 — 암호화 워크플로에서 가장 흔한 인적 오류입니다.