프라이버시와 검증 가능성, 동시에 — ECDH 선택적 복호화 키 공개 메커니즘

블록체인은 투명하다. 모든 트랜잭션은 누구나 볼 수 있다. 이것이 블록체인의 신뢰 기반이다. 그러나 동시에 이것이 블록체인의 가장 큰 딜레마다.

사기 조사 의뢰를 블록체인에 올리면? 의뢰 내용이 모두에게 공개된다. 피해자 신원, 피해 금액, 수사 방향이 공격자에게도 보인다. 이것은 조사 자체를 망친다.

그렇다면 프라이빗 블록체인으로 가면 해결되나? 투명성을 버리면 신뢰도 사라진다. 검증이 불가능해진다.

이 딜레마를 푸는 메커니즘이 있다. ECDH 기반 선택적 복호화 키 공개다.

핵심 아이디어
데이터는 암호화되어 온체인에 저장된다. 평소에는 당사자만 복호화 가능하다. 분쟁·검증이 필요한 순간에만, 필요한 대상에게만, 복호화 키를 선택적으로 공개한다.

ECDH란 무엇인가

ECDH(Elliptic Curve Diffie-Hellman)는 두 당사자가 안전하지 않은 채널을 통해 공유 비밀(shared secret)을 만드는 암호화 프로토콜이다. 1976년 Diffie-Hellman 키 교환의 타원곡선 버전으로, 더 짧은 키 길이로 더 강한 보안을 제공한다.

핵심 성질은 이것이다. Alice의 개인키와 Bob의 공개키로 만든 공유 비밀 = Bob의 개인키와 Alice의 공개키로 만든 공유 비밀. 수학적으로 동일한 값이 나온다. 그런데 이 공유 비밀은 두 사람의 개인키 없이는 제3자가 계산할 수 없다.

 // ECDH 공유 비밀 생성 원리
 Alice: 개인키 a, 공개키 A = a × G
 Bob:   개인키 b, 공개키 B = b × G
 (G = 타원곡선 생성점)

 Alice 계산: shared_secret = a × B = a × (b × G) = ab × G
 Bob 계산:   shared_secret = b × A = b × (a × G) = ab × G

 → 둘 다 동일한 shared_secret 도출
 → 제3자는 A, B만 알고 ab × G 계산 불가 (이산 로그 문제) 

이 공유 비밀을 암호화 키로 쓰면, Alice와 Bob만 해독할 수 있는 암호화 채널이 된다. 심지어 공개 블록체인 위에서도.

선택적 공개 메커니즘 — 3단계 구조

블록체인 조사 의뢰 시스템에서 이것이 어떻게 작동하는지 단계별로 보자.

1단계 — 암호화 의뢰 등록

 의뢰자 (Alice) 행동:
 1. 의뢰자 개인키 alice_priv + 조사자 공개키 bob_pub
   → shared_secret = ECDH(alice_priv, bob_pub)

 2. 조사 의뢰 내용을 shared_secret으로 AES-256-GCM 암호화
   → encrypted_content = Encrypt(investigation_brief, shared_secret)

 3. 온체인에 저장:
   · alice_pub (의뢰자 공개키)
   · encrypted_content (암호화된 의뢰 내용)
   · investigation_id
   // shared_secret은 저장하지 않음 — 계산으로만 도출 

2단계 — 승인된 조사자만 복호화

 조사자 (Bob) 행동:
 1. 온체인에서 alice_pub과 encrypted_content 읽기

 2. 자신의 개인키로 공유 비밀 도출:
   → shared_secret = ECDH(bob_priv, alice_pub)
   // Alice가 계산한 것과 수학적으로 동일

 3. 복호화:
   → investigation_brief = Decrypt(encrypted_content, shared_secret)

 제3자 (Eve) 상황:
 온체인에서 alice_pub, bob_pub, encrypted_content 모두 볼 수 있음
 그러나 shared_secret 계산 불가 (개인키 없음)
 → 복호화 영구 불가 

3단계 — 분쟁 시 선택적 키 공개

여기서 선택적 공개의 핵심이 등장한다. 분쟁이 발생했다. 검증 패널이 의뢰 내용과 조사 결과를 확인해야 한다. 그러나 영구적으로 모든 사람에게 공개할 수는 없다.

 선택적 공개 방법 A — 검증자별 재암호화:
 Alice: 각 검증자의 공개키로 별도 shared_secret 생성
 → encrypted_for_validator_1 = Encrypt(brief, ECDH(alice_priv, v1_pub))
 → encrypted_for_validator_2 = Encrypt(brief, ECDH(alice_priv, v2_pub))
 → 각 검증자가 자신의 개인키로만 복호화 가능

 선택적 공개 방법 B — 시간 제한 키 공개:
 스마트컨트랙트가 분쟁 기간(72시간) 동안만 shared_secret 공개
 → 검증 기간 종료 후 자동 폐기 (컨트랙트 상태 삭제)
 → 영구 공개 아님, 검증 목적 한정 공개

 선택적 공개 방법 C — 프록시 재암호화 (PRE):
 Alice → 위임 키 생성 → 스마트컨트랙트
 컨트랙트: Alice용 암호문을 검증자용 암호문으로 변환
 → Alice의 개인키 없이 복호화 가능하도록 변환
 → 원본 데이터는 노출되지 않음 

왜 이것이 중요한가 — 투명성 딜레마의 해결

블록체인 시스템이 직면하는 근본 모순이 있다.

요구사항	완전 공개	완전 비공개	선택적 공개
당사자 프라이버시	❌	✅	✅
제3자 검증 가능성	✅	❌	✅ (필요 시만)
수사 보안	❌ (공격자 노출)	✅	✅
온체인 신뢰	✅	❌	✅ (암호화 증명)

선택적 공개는 이 모순을 동시에 해결한다. 평소에는 암호화로 프라이버시를 보호하면서, 필요한 순간에는 키를 공개해 검증을 허용한다. 키 공개 여부도 스마트컨트랙트가 조건부로 통제한다.

실제 적용 — 분쟁 해결 시나리오

온체인 사기 조사 의뢰에서 분쟁이 발생한 상황을 보자.

분쟁 시 키 공개 흐름

상황: 의뢰자 → 조사 결과 거부 → 보상금 에스크로 잠금

1단계: 스마트컨트랙트 → 분쟁 상태로 전환 → 72시간 타이머 시작

2단계: 의뢰자 선택 A — 자신의 ECDH 키를 검증 패널 5명에게 선택적 공개
선택 B — 스마트컨트랙트에 72시간 한정 키 에스크로

3단계: 검증 패널 → 의뢰 내용 + 조사 결과 복호화 → 사실관계 확인

4단계: commit-reveal 투표 → 다수결 판정 → 에스크로 자동 해제

종료: 72시간 타이머 만료 → 공개된 키 자동 폐기 → 이후 복호화 불가

핵심은 키 공개가 시간과 범위 모두에서 제한된다는 점이다. 72시간 동안, 5명의 패널에게만. 분쟁 해결 후에는 자동으로 접근이 차단된다. 인터넷 어딘가에 영구 저장되는 것이 아니다.

영지식 증명과의 시너지

ECDH 선택적 공개의 한계 하나는 키를 공개하면 해당 내용 전체가 노출된다는 점이다. 더 정밀한 프라이버시 제어가 필요하다면 ZKP(영지식 증명)와 결합한다.

ZKP + ECDH 결합 시나리오

조사자가 의뢰 내용을 복호화하여 조사를 완료했음을 증명하되, 의뢰 내용 자체는 공개하지 않는다.

"나는 이 암호화된 데이터를 복호화했고, 그 내용을 바탕으로 이 결론에 도달했다. 복호화 사실을 수학적으로 증명하지만, 원본 데이터는 공개하지 않는다."

→ 검증 가능성 + 프라이버시 동시 달성

이것이 왜 지금 중요한가

온체인 경제가 성장하면서 민감한 거래와 의뢰가 블록체인 위로 올라오고 있다. 의료 데이터, 법적 분쟁, 기업 기밀, 개인 신원. 이것들이 "완전 공개" 또는 "완전 비공개" 중 하나를 택해야 한다면 블록체인은 이 용도에 적합하지 않다.

ECDH 선택적 복호화 키 공개는 그 사이를 연다. 암호화로 시작하되, 필요한 순간에 필요한 범위에서 검증을 허용한다. 이것이 프라이버시와 검증 가능성을 동시에 달성하는 방법이다.

핵심 원칙

투명성은 신뢰를 만든다. 그러나 모든 것을 투명하게 하면 프라이버시가 사라진다.
암호화는 프라이버시를 만든다. 그러나 모든 것을 암호화하면 검증이 불가능해진다.

선택적 공개 = 평소에는 암호화, 검증이 필요할 때만 조건부 해제.
ECDH는 이것을 중앙 신뢰 기관 없이 순수 수학으로 구현한다.

탈중앙 조사 시스템, 프라이빗 DAO 투표, 선택적 공개 DeFi 계약 — 앞으로 수년간 이 메커니즘이 적용되는 영역은 계속 확장될 것이다.