조언: PIE 비보관 컴퓨팅 모델에서의 중요한 발견
모델은 작업이 끝나면 운영자의 모든 암호 해독 능력을 제거합니다. 장치는 여전히 모델이 신뢰할 수 없다고 지정한 단일 구성요소가 게시한 검증되지 않은 공개키로 암호화합니다.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
저는 25년 동안 시스템을 구축해 왔으며, 의도적으로 설계되고 운영상 가벼운 것을 만드는 것을 좋아합니다. 그 벡터가 그 무게를 얻는 만큼만 운반합니다.그 접근 방식에서 사용자의 데이터를 최소화하는 것은 명백한 이유를 넘어서는 이유로 항상 의미가 있었습니다. 그들의 데이터 주권은 중요합니다. 그 아래에는 더 단순한 것이 있습니다: 사물은 그 자리에 있어야 합니다. 제가 만드는 대부분은 처리이며, 처리 아키텍처는 다른 역할을 수행할 수 없습니다. 필요하지 않은 기록을 보유하는 것은 아무 가치도 없는 벡터입니다. 이를 최적화로 보지 않고 규정 준수 연습으로 보지 않는 것이 설계를 정직하게 유지합니다 — 그리고 그렇게 구축된 시스템은 규제와 자연스럽게 좋은 관계를 유지합니다. 규제할 것이 거의 없기 때문입니다.그래서 Mary Camacho의 발표가 X 피드에 나타났을 때, 저는 그녀의 아키텍처를 제 자신의 것처럼 읽었습니다. 그녀는 핵심을 Creative Commons 라이선스 하에 공개 기록에 게시했으며, 엔지니어가 재구성할 수 있을 만큼의 세부 수준을 제공했고, 기존 기술에 대해 직접적으로 언급했습니다.시퀀스를 따라가며, 저는 서버 내부에 적대적 엔터티를 배치하고 그가 도달할 수 있는 것을 추적했습니다. 그는 작업자를 앞질 수 있었습니다.그 뒤에 거의 모든 작업은 음성 대화를 통해 진행되었습니다 — 30 음성 메모를 통해, 소리 내어 생각하고 다양한 각도에서 우려를 테스트하면서, 그것이 견디거나 무너질 때까지.제가 눈치챈 것은: 장치는 클레임 기록을 먼저 작성한 사람에게 암호화합니다#
공개는 운영 순서를 직접 명시합니다. 작업자는 작업을 주장하고 키를 게시한 다음에만 장치가 암호화합니다:장치 측의 그 합의는 동일한 정밀도로 지정됩니다:— §2.1, 데이터 흐름(작업당)
- 작업자 → 조정: 작업을 폴링하고 주장(한 번만 쓰기, 첫 번째 승리), 작업자의 공개 키를 게시합니다.
- 장치 ← 조정: 폴링, 작업자의 공개 키를 검색, 공유 비밀을 도출, 페이로드를 암호화합니다.
장치는 작업자의 공개 키를 알게 되면 자체 X25519 교환과 작업자 키에 대한 ML-KEM 캡슐화를 수행하여 자체 공개 기여( X25519 공개 키 ‖ ML-KEM 암호문)와 공유 비밀을 생성합니다.— §4.2, 작업자 수명 주기에 바인딩알게 된 순간. 19 페이지 전반에 걸쳐 작업자의 일시 공개 키에 대한 서명, 인증서, 장치가 평가하는 인증서, 사전 공유 비밀이 없습니다. 그 부재는 의도적이며 강점으로 제시됩니다: 모델은 인증 문서, TPM 인용, 측정 부트 아티팩트 없이 복호화를 차단하고 사전 프로비저닝된 작업자 비밀을 보관하지 않습니다.따라서 장치는 클레임 기록에 있는 공개 키에 페이로드를 암호화하며, 합법적인 작업자의 키를 다른 사람의 키와 구분할 수 있는 수단이 없습니다. 클레임을 먼저 작성할 수 있는 모든 당사자는 장치가 암호화하는 당사자가 되며, 신뢰된 페이로드는 그들의 손에 복호화됩니다.
flowchart TB
subgraph BEFORE["이전: 게시된 대로"]
direction TB
A2{"누가 먼저 주장합니까?"} -->|실제 작업자| A3["진짜 키"]
A2 -->|다른 작성자| A4["공격자 키"]
A3 --> A5["장치가 암호화합니다"]
A4 --> A5
A5 --> A6["키 보유자가 읽을 수 있습니다"]
end
subgraph AFTER["이후: 서명된 키"]
direction TB
B2{"서명이 유효합니까?"} -->|예| B3["검증된 작업자 키"]
B2 -->|아니오| B4["거부, 재시도"]
B3 --> B5["실제 작업자만 읽습니다"]
end
A6 ~~~ B2Copy source암호화는 견고하며 도입은 인증되지 않는다#
공격자는 아무것도 깨뜨리지 않는다. X25519 그리고 ML-KEM-768 둘 다 정확히 지정된 대로 작동합니다. 공격자는 키를 제공하고 합의의 정당한 당사자가 된다.이는 인증되지 않은 키 동의이며, 그 실패 모드는 분야에서 가장 오래된 결과이다. Plain Diffie-Hellman은 아무도 인증하지 않으며, 자신의 공개 키를 대체하는 당사자에게 넘어간다. 키 캡슐화 메커니즘은 그 특성을 상속받으며, 이 때문에 RFC 9180는 수신자의 공개 키의 진위 여부를 자체 범위 밖에 두고, 주변 애플리케이션이 인증서, 키 디렉터리 또는 오프밴드 검증을 통해 이를 설정한다고 가정합니다. 이 모델은 주변 애플리케이션이며, 수신자 키를 배포하는 데 사용되는 채널은 자체 신뢰 모델이 신뢰할 수 없다고 라벨링한 구성 요소입니다.공개는 인접 공격을 예상하고 이를 닫는다:주장은 일회성/첫 승리이며, 이후 작업자는 작업의 키 교환을 탈취할 수 없습니다.— §6, 참조 구현그러한 추론은 타당하며 메커니즘은 말한 대로 작동합니다. 두 개의 대칭 경우 중 하나를 다룹니다.
| 위협 | 한 번 쓰기 주장으로 처리됨 |
|---|---|
| 두 번째 작업자가 기존 주장을 덮어씁니다 | 예 — 쓰기가 거부됩니다 |
| 무단 당사자가 먼저 주장을 씁니다 | 아니요 — 첫 번째 쓰기가 승리합니다 |
중간자(게이트웨이, 조정, 저장, 모니터)는 비밀을 도출할 수 있는 충분한 키 자료를 결코 보유하지 않습니다. 조정 또는 저장을 손상시키는 공격자는 불투명한 블롭과 공개 키만을 얻습니다.— §4.3, 독립적인 방향별 키첫 번째 문장은 정확합니다. 두 번째 문장은 읽는 공격자를 묘사합니다. 쓰는 공격자는 장치가 폴링하기 전에 주장 기록에 선택된 공개 키를 삽입하고, 정당한 비밀을 도출하는 것이 상대방이 될 수 있는 당사자에게는 필요하지 않게 만듭니다. 그 기록의 내용을 관리하는 사람은 페이로드를 읽을 수 있는 사람을 관리하며, 이는 조정 계층을 기밀성에 대한 신뢰할 수 있는 구성 요소로 만듭니다 — §3가 말하는 유일한 것은 장치와 작업자 외에는 어떤 구성 요소도 결코 존재해서는 안 된다는 것입니다.주장의 정직한 한계: 이는 오늘날 공개 인터넷의 누구도 이 데이터를 읽을 수 없다는 것을 의미하지는 않습니다. 실제 배포에서는 주장을 쓰는 능력이 클라우드 네트워킹과 자격 증명 뒤에 있으며, 공개는 장치 경로의 인증 게이트웨이를 설명합니다. 정확한 문제는 기밀성이 이제 그 주변에 달려 있다는 점이며, 아키텍처의 중앙 약속은 장치와 작업자 사이의 구성 요소를 신뢰하지 않고도 유지된다는 것입니다.