Dusk의 PLONK 구현체에서 발견된 '검증되지 않은 평가값' 취약점

도입

영지식 증명(Zero-Knowledge Proof, ZKP)을 실서비스에 쓰는 곳들이 늘면서, 이 분야의 보안 감사 결과들이 점점 무거워지고 있는데요. 최근 OtterSec(osec.io)이 Dusk Network의 PLONK 구현체를 감사한 결과를 공개했어요. 결론부터 말하자면, 검증자(Verifier)가 일부 평가값(evaluation)을 검증하지 않고 그냥 받아들이는 버그가 있었다는 이야기입니다. 이게 왜 중요하냐면, ZKP의 핵심은 "증명자가 거짓말을 못 하게 막는 것"이거든요. 그런데 검증해야 할 값을 검증하지 않으면, 누군가 거짓말을 끼워 넣어도 통과될 수 있다는 뜻이에요.

PLONK가 뭔데요?

ZKP 분야에서 가장 인기 있는 증명 시스템 중 하나가 PLONK입니다. 이름은 어렵지만 아이디어는 단순해요. 어떤 계산을 했다는 사실을, 그 계산 내용을 공개하지 않고 증명할 수 있게 해주는 방식이에요. 예를 들어 "내가 비밀번호를 알고 있다"는 사실을 비밀번호를 보여주지 않고 증명할 수 있는 거죠.

PLONK는 다항식(polynomial)들의 관계를 이용해서 이걸 만들어내요. 증명자(Prover)는 여러 다항식을 만든 다음, 검증자가 무작위로 고른 한 점에서 그 다항식들의 값을 알려주고, 그 값들이 정해진 관계식을 만족한다는 걸 보여주는 식이에요. 이때 "이 값이 진짜로 약속한 그 다항식에서 나왔다"는 걸 증명하는 데 KZG 약속(commitment)이라는 암호 도구가 쓰입니다.

무엇이 문제였나

이번 감사에서 발견된 문제는, Dusk의 PLONK 구현체에서 일부 다항식의 평가값을 검증자가 검증하지 않고 그대로 사용하고 있었다는 점이에요. 좀 더 풀어 말하면, PLONK의 안전성은 "증명자가 보낸 모든 평가값이 실제로 약속된 다항식에서 나온 값이라는 것"을 KZG 검증 단계에서 확인하는 데서 나옵니다. 그런데 코드에서 일부 평가값에 대해 이 검증 단계가 빠져 있었던 거예요.

이렇게 되면 악의적인 증명자가 임의의 가짜 값을 평가값으로 끼워 넣어도 검증을 통과할 수 있게 됩니다. 사실상 위조된 증명을 받아들일 수 있다는 뜻이고, ZKP가 보장하던 "건전성(soundness)"이 깨진 셈이에요. 보고서에 따르면 영향을 받는 함수들에서 이 누락된 평가값들을 최종 짝맞춤(pairing) 검사식에 포함시키도록 수정하는 게 패치의 핵심이에요.

업계 맥락

ZKP 라이브러리에서 이런 류의 버그가 처음은 아닙니다. 몇 년 전 "Frozen Heart"라고 알려진 일군의 취약점들도 결국 "Fiat-Shamir 변환에서 어떤 값을 해시 입력에 빼먹었다"는 패턴이었거든요. 이번 Dusk 사례도 본질적으로 비슷해요. "꼭 검증해야 하는 입력을 검증 식에서 빼먹었다."

PLONK 계열을 쓰는 프로젝트는 zkSync, Polygon zkEVM, Scroll, Aztec 등 굉장히 많은데, 각자 구현이 조금씩 달라서 한 군데의 버그가 다른 곳에 그대로 있다고 보기는 어려워요. 다만 "누락 검증" 패턴 자체는 공통 함정이라, 다른 구현체들도 이번 보고서를 참고해서 점검해볼 가치가 충분합니다.

한국 개발자에게 주는 시사점

국내에서도 ZKP를 활용한 프라이버시 코인, 익명 인증, ZK-롤업 같은 시도가 점차 늘고 있는데요. 이런 영역에서는 "암호 라이브러리는 검증된 걸 쓰자"는 원칙이 특히 중요하다는 걸 다시 보여주는 사례예요. PLONK 같은 증명 시스템을 직접 구현하는 건 정말 권하지 않고, arkworks·plonky2·gnark처럼 오랫동안 검토받은 라이브러리를 쓰되 새 버전이 나올 때마다 감사 보고서를 챙겨보는 습관이 필요합니다.

그리고 ZKP를 "마법 같은 보안 도구"로 막연히 받아들이지 말고, 그 안전성이 어떤 가정 위에 서 있는지 이해하는 게 점점 중요해져요. "이 평가값이 정말 약속된 다항식에서 나온 값이다" 같은 작은 검증 하나가 빠지면 전체 시스템이 무너지거든요.