AI가 Cloudflare의 암호화 라이브러리 CIRCL에서 실제 버그 7개를 찾아낸 이야기

TL;DR Highlight

zkSecurity 팀이 AI 감사 파이프라인을 Cloudflare의 오픈소스 암호화 라이브러리 CIRCL에 돌려서 실제로 존재하는 버그 7개를 발견했고, 그 중에는 속성 기반 암호화의 접근 제어를 완전히 우회할 수 있는 Critical 버그도 포함되어 있다. AI가 암호화 코드 감사에서 실질적인 성과를 낼 수 있음을 보여준 사례라 주목할 만하다.

Who Should Read

암호화 라이브러리를 직접 개발하거나 오픈소스 암호화 코드를 프로덕션에 사용하는 보안 엔지니어 및 백엔드 개발자. AI 기반 코드 감사 도구의 실제 효용성이 궁금한 개발자에게도 유용하다.

Core Mechanics

zkSecurity 팀은 zkao라는 AI 감사 에이전트를 개발 중이다. 목표는 AI가 코드를 지속적으로 분석해서 다른 AI 도구가 찾을 수 있는 버그를 모두 찾아내는 것이고, 이번 실험은 그 과정에서 나온 결과물이다.
실험은 두 가지 설정으로 진행됐다. 하나는 LLM 단독으로 간단한 프롬프트만 사용한 것이고, 다른 하나는 팀 전문가가 작성한 '스킬(skills)'을 추가해 도메인 지식을 보강한 것이다. 스킬을 붙였을 때 더 복잡하고 심각한 버그를 찾아냈다.
7개 버그 중 가장 심각한 건 Bug 7인 CP-ABE(속성 기반 암호화, 특정 속성을 가진 사람만 복호화할 수 있게 하는 암호화 방식)의 AND-share 로직 버그다. 이 버그는 접근 제어를 완전히 우회할 수 있어서 AI와 Cloudflare 모두 Critical로 평가했고, fix commit은 def2fd3이다.
Bug 1은 threshold RSA(비밀 키를 여러 참여자에게 분산해서 일정 수 이상이 협력해야 서명 가능한 방식)의 다항식 계산에서 발생했다. 계수는 big.Int로 제대로 처리했지만, x^i 계산을 float64로 했기 때문에 큰 숫자에서 정밀도 손실이 생겼다. 암호화 코드에서 float를 쓰는 건 매우 이례적인 실수다.
Bug 3인 BLS 집계 서명(여러 서명을 하나로 합치는 방식)에서 메시지 유일성(message distinctness) 검증이 빠져 있었다. 이 버그는 AI가 Medium으로 평가했지만 Cloudflare는 High로 확인했고, AI의 심각도 판단이 항상 정확하지 않다는 걸 보여주는 사례다.
AI가 판단한 심각도와 Cloudflare가 최종 확인한 심각도 사이에 꽤 큰 차이가 있었다. Bug 1은 AI가 Critical로 봤지만 Cloudflare는 Low로, Bug 3은 AI가 Medium으로 봤지만 Cloudflare는 High로 평가했다. AI의 심각도 판단 자체는 아직 신뢰하기 어렵다는 게 팀의 결론이다.
AI가 만들어낸 후보 발견(candidate findings)을 최종 보고서로 만들기 위해 사람이 각각 검증하고, 실제로 악용 가능한지 확인하고, POC(개념 증명 코드)를 최소화하는 작업이 필요했다. AI 후보 발견은 저렴하지만 신뢰할 수 있는 보고서를 만드는 데는 여전히 사람의 손이 필요하다고 팀은 강조한다.
7개 버그는 모두 현재 upstream에 수정됐고, 대부분 HackerOne의 Cloudflare 버그 바운티 프로그램을 통해 바운티를 받았다. zkao로 재검증했을 때 7개 모두 현재 버전의 zkao에서도 일관되게 재현됐다.

Evidence

한 댓글에서 'AI 후보 보고서가 몇 개나 나왔는지, 그 중 실제 버그 7개가 나온 비율이 어느 정도인지'를 물었다. 이는 false positive(실제로 없는 버그를 있다고 잘못 판단) 비율이 얼마나 되는지를 묻는 것으로, AI 감사 도구의 실용성을 평가하는 핵심 질문이지만 원문에서는 명확한 수치가 공개되지 않았다.
CP-ABE 접근 제어 버그와 관련해서 '왜 기본적인 테스트(속성이 없는 사용자는 복호화 불가 여부)가 없었냐'는 질문이 나왔다. 댓글 작성자는 '비밀번호를 틀렸을 때 로그인이 안 된다는 걸 테스트하지 않은 것과 비슷한 상황'이라고 비유했다. fix commit에는 regression test가 추가됐지만 상위 레벨 테스트가 왜 처음부터 없었는지에 대한 의문은 남아 있다.
암호화 코드에서 float64를 쓴 것에 대해 '암호화에 float를 사용한다니 충격적'이라는 반응이 있었다. DJB(다니엘 번스타인, 유명 암호학자)가 성능 최적화를 위해 FPU를 특수하게 활용한 사례는 있지만, 일반적인 방식으로 float를 암호 알고리즘에 쓰는 건 매우 이례적이라는 지적이다.
zkao가 정확히 무엇인지에 대한 혼란이 있었다. '코드베이스에 LLM 감사를 지속적으로 실행하는 시스템'이라는 설명과, 'LLM이 찾은 취약점 보고서에 대해 추가로 실행한다'는 설명이 공존해서 독자가 헷갈렸다. zkao가 단순한 LLM 래퍼인지 아니면 더 고도화된 시스템인지가 명확히 설명되지 않았다는 의견이 있었다.

How to Apply

암호화 라이브러리를 직접 개발하거나 검토하는 경우, 다항식 계산이나 지수 연산에 float64를 사용하는 코드가 있는지 먼저 점검하라. 암호화 코드에서는 big.Int나 정수 연산만 써야 하며, math.Pow(float64(x), float64(i)) 같은 패턴이 있으면 즉시 제거해야 한다.
BLS 집계 서명이나 DLEQ(이산 로그 동등성 증명) 같은 암호화 프로토콜을 구현할 때는 메시지 유일성 검증처럼 프로토콜 명세에서 명시적으로 요구하는 전제 조건을 구현 코드 레벨에서도 강제하고 있는지 확인하라. 이런 조건이 빠지면 심각한 보안 취약점이 생긴다.
속성 기반 암호화(ABE)나 접근 제어 기반 암호화 시스템을 구현했다면, 필수 속성이 없는 사용자가 복호화를 시도했을 때 실제로 실패하는지를 검증하는 상위 레벨 통합 테스트를 반드시 추가하라. 단위 테스트만으로는 이런 종류의 로직 버그를 잡기 어렵다.
AI 기반 코드 감사 도구를 보안 프로세스에 도입하려는 경우, AI가 제출한 후보 발견(candidate findings)의 심각도 판단을 그대로 믿지 말고 반드시 사람이 재검증하는 단계를 유지하라. 이번 사례에서 AI 판단과 실제 심각도가 크게 다른 경우가 여러 건 있었다.

Code Example

snippet

// Bug 1: float64를 사용한 잘못된 코드 (tss/rsa/rsa_threshold.go)
xi := int64(math.Pow(float64(x), float64(i)))
// 큰 수에서 float64 정밀도 손실 발생 → 암호화 연산 결과 오염

// 올바른 방향: big.Int를 사용한 정수 지수 계산
xi := new(big.Int).Exp(big.NewInt(int64(x)), big.NewInt(int64(i)), nil)

Terminology

Threshold RSARSA 개인 키를 여러 참여자에게 나눠서 보관하고, 일정 수 이상이 협력해야만 서명이 가능한 방식. 단일 실패 지점을 없애기 위한 암호화 기법.

CP-ABECiphertext-Policy Attribute-Based Encryption의 약자. '이 암호문은 A와 B 속성을 모두 가진 사람만 열 수 있다'처럼 정책 기반으로 암호화하는 방식.

DLEQDiscrete Logarithm Equality Proof의 약자. '나는 이 두 값이 같은 비밀 키로 만들어졌다는 걸 비밀 키를 공개하지 않고 증명할 수 있다'는 영지식 증명 기법.

BLS aggregate signature여러 사람의 서명을 수학적으로 하나로 합쳐서 검증 비용을 줄이는 서명 방식. 블록체인 등에서 많이 쓰인다.

HPKEHybrid Public Key Encryption의 약자. 공개 키 암호화와 대칭 키 암호화를 결합해서 효율과 보안을 동시에 잡는 현대적 암호화 표준.

candidate findingAI가 버그일 수 있다고 제출한 후보 발견. 최종 확인 전 단계라 false positive가 섞여 있을 수 있고, 사람이 검증해야 신뢰할 수 있는 보고서가 된다.