키가 기기를 절대 떠나지 않는 이유

CardanoWall에서는 개인 키가 기기 안에 머뭅니다. 서명하고 봉인하고 시험 복호화하고 검증하는 소프트웨어는 로컬에서 실행되며, 호스팅된 게이트웨이는 사용자의 신원 시드(Identity Seed), 서명 키, 수신 키, 봉인된 파일을 복호화하는 자료를 절대 받지 않도록 설계되어 있습니다.

게이트웨이는 그런 비밀 없이도 할 일이 충분히 많습니다. 가격 견적을 내고, 저장할 암호화된 암호문을 받고, Cardano 트랜잭션을 제출하고, 레코드를 색인하고, 잔액을 추적할 수 있습니다. 이 가운데 어느 것도 작성자임을 증명하거나 봉인된 페이로드를 여는 키를 필요로 하지 않습니다. 이 분리는 의도된 것입니다. 서비스는 증명을 옮기는 일을 돕고, 비밀은 사용자가 간직합니다.

어떤 키를 말하는 것입니까?

Label 309 신원은 단 하나의 값에서 출발합니다. 바로 32바이트의 **신원 시드(Identity Seed)**입니다. 이 시드로부터, 표준을 따르는 모든 소프트웨어는 신원이 실제로 사용하는 키를 세 가지 역할로 파생합니다.

레코드에 서명하는 Ed25519 키;
클래식 방식으로 봉인된 레코드를 수신하는 X25519 키;
포스트 양자 방식으로 봉인된 레코드를 수신하는 하이브리드 포스트 양자 키.

파생은 결정론적입니다. 같은 32바이트는 어떤 표준 준수 클라이언트에서든 항상 같은 키쌍 세 개를 만들어 냅니다. 바로 이 점이 시드를 이식 가능하게 만들고, 동시에 지킬 가치가 있는 유일한 대상으로 만듭니다. 시드를 가진 사람은 누구든 신원을 복원하고, 그 신원으로 서명하고, 그 신원에게 보내진 봉인된 레코드를 복호화할 수 있습니다. 그래서 시드는 비공개로 유지되며, 아래의 모든 것이 여기서 비롯됩니다.

클라이언트는 로컬에서 무엇을 합니까?

클라이언트는 개인 키에 닿는 모든 작업을 처리합니다.

신원 시드를 생성하거나 가져오기;
시드에서 서명 키와 수신 키를 파생하기;
레코드에 서명하기;
업로드 전에 파일을 암호화하기;
콘텐츠 키를 감싸는 봉인된 수신자 슬롯을 만들기;
들어오는 레코드를 시험 복호화하여 자신에게 보내진 것을 찾기;
암호문을 복호화하고 평문 해시를 다시 계산하기;
서명과 레코드 구조를 검증하기.

웹 앱, 데스크톱 앱, 명령줄 도구, 그리고 SDK 위에 만들어진 모든 소프트웨어는 키를 저장하는 방식과 잠금을 해제하는 방식이 서로 다릅니다. 하지만 그 사이에서 원칙은 바뀌지 않습니다. 개인 키 자료는 게이트웨이로 전송되지 않습니다.

그렇다면 게이트웨이는 무엇을 합니까?

게이트웨이는 게시 파이프라인을 실행합니다. 게이트웨이는 다음을 할 수 있습니다.

견적을 계산하기;
이미 암호화된 암호문을 받아 콘텐츠 주소 지정 URI를 반환하기;
준비된 증명 레코드를 받기;
Cardano 트랜잭션을 제출하고 확인을 기다리기;
체인 재구성을 처리하고, 게시가 영구히 실패하면 자동으로 환불하기;
레코드를 공유 피드로 색인하기;
계정 잔액을 추적하기;
API를 노출하고 라이프사이클 이벤트를 내보내기.

이는 실제 업무이며, 운영 작업의 대부분을 차지합니다. 그러나 이 가운데 어느 것도 사용자의 봉인된 콘텐츠를 복호화하는 키를 필요로 하지 않습니다. 게이트웨이는 전송 및 운영 계층입니다. 게이트웨이는 사용자의 신원 볼트가 아니며, 그렇게 동작하도록 설계되지도 않았습니다.

이 분리가 왜 중요합니까?

증명은 그것을 만드는 데 도움을 준 서비스를 신뢰하지 않고도 검증 가능한 상태로 남아야 하기 때문입니다.

호스팅된 서비스가 사용자 키의 유일한 사본을 보유한다면, 그 서비스가 사용자의 신뢰 근원이 됩니다. 그 서비스가 종료되거나, 약관을 바꾸거나, 침해를 당하거나, 계정을 잠근다면, 사용자가 서명하고 복호화하고 심지어 검증하는 능력까지도 그 서비스에 달리게 됩니다. 바로 그 상황을 피하기 위해 Label 309가 만들어졌습니다.

Label 309 레코드는 공개 데이터로 검증할 수 있습니다. 검증기는 트랜잭션 메타데이터, 선택적으로 콘텐츠 바이트, 그리고 공개 Cardano 익스플로러만 있으면 됩니다 — 어떤 단계에서도 발행자 서버가 필요 없습니다. 봉인된 레코드는 키 보유자가 열 수 있습니다. 서명된 레코드는 그 서명 키에 대조해 확인할 수 있습니다. 게이트웨이는 게시를 훨씬 쉽게 만들 수 있지만, 설계상 단지 레코드를 온체인에 올리는 일을 도왔다는 이유만으로 제대로 봉인된 페이로드를 읽을 수는 없습니다.

이것이 증명을 가지고 있다고 말하는 서비스와 스스로 성립하는 증명의 차이입니다.

게이트웨이가 내 봉인된 파일을 읽을 수 있습니까?

클라이언트가 콘텐츠를 올바르게 봉인했다면, 읽을 수 없습니다 — 게이트웨이는 오직 암호문만 봅니다.

봉인된 레코드의 구성은 다음과 같습니다. 공개된 온체인 레코드는 평문 해시에 커밋합니다 — 그 해시와 블록 타임이 시점에 대한 증명입니다. 암호화된 페이로드 자체는 절대 온체인에 올라가지 않습니다. 그것은 콘텐츠 주소 지정 URI(예: ar://)에 존재합니다. 콘텐츠 키는 하나 이상의 수신자 공개 키로 감싸지며, 수신자마다 슬롯이 하나씩 있습니다. 수신자(또는 발신자)는 암호문을 가져와 로컬에서 복호화하고, 평문 해시를 다시 계산하여 온체인 커밋과 일치하는지 확인합니다.

게이트웨이는 봉인된 레코드가 존재한다는 사실을 볼 수 있고, 암호문 크기, 업로드 시점, 계정 활동, 트랜잭션 상태, 공개 메타데이터를 관찰할 수 있습니다. 하지만 평문을 보도록 설계되지는 않았으며, 올바른 개인 키가 없으면 암호문은 읽을 수 없는 상태로 남습니다. 여기에 솔직한 단서 두 가지가 따라붙습니다. 봉인은 기밀성을 보호하지 익명성을 보호하지는 않습니다 — 관찰 가능한 메타데이터는 여전히 메타데이터입니다 — 그리고 파일을 복호화한 수신자는 그 뒤에 언제든 평문을 유출하기로 선택할 수 있습니다. 암호화는 전송 중과 저장 중의 바이트를 보호하는 것이지, 권한이 있는 독자가 그다음에 무엇을 하는지까지 보호하지는 않습니다.

게이트웨이가 유효한 증명을 위조할 수 있습니까?

유효하지 않은 증명이 독립적인 검증을 통과하도록 만들 수 없게 설계되어 있습니다.

검증기는 온체인 레코드, 레코드 구조, 해시, 서명, 그리고 — 자신이 열 수 있는 봉인된 레코드라면 — 다시 계산한 평문 해시를 확인합니다. 게이트웨이가 트랜잭션에 대해 거짓말을 하거나, 레코드 바이트를 바꾸거나, 서명을 빠뜨리거나, 커밋된 해시와 맞지 않는 바이트를 가리킨다면, 독립적인 검증기가 이를 잡아내야 합니다.

이는 정확한 약속이므로 과장하지 않는 편이 좋습니다. 게이트웨이는 여전히 일상적인 운영 측면에서 오작동할 수 있습니다. 게시에 실패하거나, 트랜잭션을 지연시키거나, 오류를 반환하거나, 자신의 상태를 잘못 보고하거나, 장애를 겪거나, 좋지 않은 경험을 줄 수 있습니다. 게이트웨이가 할 수 없어야 하는 것은 유효하지 않은 증명을 공개 데이터에 대조해 깔끔하게 검증되는 증명으로 둔갑시키는 일입니다. 편의는 실패할 수 있지만, 암호학적 클레임은 게이트웨이의 정직함에 의존하지 않습니다.

웹 앱은 구체적으로 어떻습니까?

웹 앱은 브라우저에서 실행되는 소프트웨어이며, 이 점이 그 신뢰 모델을 결정합니다.

여기서 관련된 경계에는 브라우저, 로드되는 애플리케이션 코드, 설치된 모든 확장 프로그램, 기기 자체, 그리고 잠금 해제 흐름이 포함됩니다. 브라우저는 편리하지만, 사용자가 직접 통제하는 빌드에서 실행되는 데스크톱 볼트나 명령줄 도구와 같은 환경은 아닙니다. 잠금이 해제된 세션 안의 악성 스크립트는 메모리에 있는 비밀을 읽을 수 있습니다. 엄격한 콘텐츠 보안 정책, 최소한의 스크립트, 명시적인 잠금 해제 단계는 그 노출을 줄여 주지만, 어떤 웹 앱도 그것을 완전히 없앤다고 주장할 수는 없습니다.

이것이 전용 데스크톱 클라이언트가 존재하는 한 가지 이유입니다. 키를 로컬에 저장하고 키를 보관하는 방식을 더 단단히 통제하고 싶은 사람들을 위한 것입니다. 각 클라이언트가 키를 보호하는 방식은 서로 다르더라도, 이 불변항은 모든 클라이언트에 걸쳐 유지됩니다 — 게이트웨이는 사용자의 개인 키를 필요로 하지 않습니다. 경계가 어디에 놓이는지에 대한 더 자세한 설명은 CardanoWall이 볼 수 있는 것과 볼 수 없는 것을 참고하십시오.

데스크톱 앱은 어떻습니까?

CardanoWall Desktop은 처음부터 로컬 암호화된 볼트를 중심으로 만들어진, 오픈소스 크로스 플랫폼 애플리케이션입니다.

Rust 코어가 신원 볼트, 암호화, 동기화 엔진, 시험 복호화, 검증을 담당하고, 웹뷰는 인터페이스만 렌더링합니다. 시드와 파생된 개인 키는 평범한 JavaScript 문자열로 웹뷰에 넘겨지지 않습니다. 콘텐츠를 미리 보아야 할 때, 복호화된 바이트는 페이지를 문자열로 통과하는 대신 전용 채널을 통해 뷰로 스트리밍됩니다. 비밀은 게이트웨이로 전송되지 않으며, 렌더러로 넘어가지도 않습니다.

이 아키텍처는 공격 표면을 좁힙니다. 다만 없애지는 않습니다. 침해된 운영 체제, 악성 의존성, 키로거, 또는 사용자가 승인한 악성코드는 여전히 로컬 보안을 무력화할 수 있습니다 — 어떤 데스크톱 지갑이든 지니는 똑같은 솔직한 한계입니다. 키를 게이트웨이 밖과 렌더러 밖에 두는 것은 의미 있는 개선이지, 완전히 침해된 호스트에 대한 보장은 아닙니다. 자세한 작동 방식은 CardanoWall Desktop 개요와 오프라인 증명을 참고하십시오.

명령줄 도구와 SDK는 어떻습니까?

이들이 중요한 이유는 웹사이트 없이도 같은 모델을 쓸 수 있게 해 주기 때문입니다.

개발자는 시드를 로컬에 보관하고, 레코드에 로컬에서 서명하고, 파일을 로컬에서 봉인하고, 어떤 게이트웨이를 통해서든 제출할 수 있습니다. 지속적 통합 시스템은 신원 자료를 팀 자체 통제 아래에 두면서 범위가 지정된 API 자격 증명으로 게시할 수 있습니다. 기업은 자체 클라이언트를 만들거나 Label 309를 기존 소프트웨어에 녹여 넣을 수 있습니다. 어떤 인터페이스를 선택하든 분담은 동일합니다. 게이트웨이는 게시하고, 클라이언트는 비밀을 간직합니다.

명령줄 도구와 SDK는 오픈소스이며 게이트웨이 비종속적이므로, 이 경계는 신뢰에 맡겨야 하는 것이 아니라 직접 들여다볼 수 있는 것입니다.

게이트웨이로 절대 보내면 안 되는 것은 무엇입니까?

다음을 게이트웨이로 — 또는 어떤 웹사이트로든 — 절대 보내지 마십시오.

L309-SEED-1… 신원 시드;
16진수 형태의 원시 시드;
서명 개인 키;
X25519 수신 개인 키;
하이브리드 포스트 양자 수신 비밀;
봉인된 콘텐츠를 복호화하는 패스프레이즈;
비공개로 두려던 평문.

게이트웨이는 공개 키, 공개 서명, 공개 레코드 바이트, 암호문, 견적 식별자, API 토큰, 계정 식별자를 정당하게 필요로 할 수 있습니다. 이들은 비공개 신원 자료가 아닙니다. 규칙은 단순합니다. 어떤 작업 흐름이 비밀을 어딘가에 붙여 넣으라고 요구한다면, 멈추고 왜 그런지 물어보십시오.

여전히 주의가 필요한 것은 무엇입니까?

로컬 키는 그 주변 환경만큼만 안전합니다. 암호화는 게이트웨이가 사용자의 비밀에 접근하지 못하게 막아 주지만, 사용자가 공격자가 통제하는 양식에 직접 복사해 넣은 시드까지 보호할 수는 없습니다. 그래서 다음이 여전히 필요합니다.

신원 시드를 보호하고 실제 백업을 보관하기;
민감한 것을 봉인하기 전에 수신자의 수신 주소를 확인하기;
피싱 사이트를 피하기;
브라우저 확장 프로그램에 대해 신중하기;
기기를 최신 상태로 유지하기;
적절한 곳에 디스크 암호화를 사용하기;
복호화된 파일이 어떻게 캐시되는지 이해하기;
데스크톱 도구와 명령줄 도구의 신뢰할 수 있는 빌드를 실행하기;
공유 작업 흐름이나 팀 작업 흐름에 키 관리 정책을 설정하기.

실패 양상에 대해서는 솔직하게 짚어 둘 필요가 있습니다. 그 양상이 대칭적이지 않기 때문입니다. 시드를 잃고 게다가 잠금 해제 요소까지 잃으면, 그 신원의 향후 사용은 사라집니다 — 다만 이미 게시한 증명은 공개 데이터로 영원히 검증됩니다. 도난당한 시드는 신원 전체의 침해입니다. 이에 대한 대응은 비밀번호를 재설정하는 것이 아니라, 새 신원을 생성하고 기존 신원을 비활성화하는 것입니다. 재설정은 없습니다. 그것이 수탁자가 없다는 것의 대가입니다.

이것이 오픈 표준에 왜 중요합니까?

오픈 증명 표준은 신뢰할 수 있는 단일 운영자에 의존해서는 안 됩니다.

CardanoWall이 내일 사라진다 해도, Label 309 레코드는 여전히 의미를 지녀야 합니다. 어떤 기업이 자체 게이트웨이를 운영하더라도, 그 레코드는 여전히 표준을 따라야 합니다. 사용자가 시드를 다른 표준 준수 클라이언트로 내보내면, 그 클라이언트는 정확히 같은 키를 파생해야 합니다. 이는 경계가 깨끗하게 유지될 때만 작동합니다. 레코드는 표준을 따르고, 검증은 독립적이며, 게이트웨이는 대체 가능하고, 클라이언트는 비밀을 간직하며, 사용자는 신원 근원을 언제든 직접 백업할 수 있습니다.

그래서 "키는 기기를 절대 떠나지 않는다"는 구호가 아닙니다. 이는 존재 증명을 이식 가능하게 만드는 요소의 일부입니다 — 이 서비스를 포함한 어떤 단일 서비스도 뛰어넘어 가지고 다닐 수 있는 증명 말입니다.

짧게 정리하면

게이트웨이는 증명을 게시하는 일을 돕습니다. 클라이언트는 비밀을 간직합니다.

개인 키는 게이트웨이로 전송되지 않습니다. 콘텐츠는 업로드 전에 암호화됩니다. 복호화는 로컬에서 이루어집니다. 검증은 서비스의 말을 신뢰하는 데 의존하지 않습니다. 이것이 CardanoWall이 기반으로 삼는 보안의 형태이며 — Label 309가 열어 두도록 설계된 형태입니다.

더 읽어보기

당신의 신원은 시드입니다 — 신원 시드가 무엇이며 왜 그것이 진짜 백업인지.
CardanoWall이 사용자의 신원을 저장하는 방식 — 암호화된 볼트와, 서버가 복호화할 수 있는 것과 없는 것.
증명이 증명하지 못하는 것 — 시점·무결성 증명의 솔직한 한계.
Label 309 표준은 label309.org에 있으며, Cardano CIP 절차에 제출되어 CIP 편집자의 검토를 받고 있습니다.
오픈소스 클라이언트, SDK, 게이트웨이는 github.com/cardanowall에 있습니다.