- 보안 감사 업체 zkSecurity가 LLM 감사 파이프라인으로 Cloudflare의 오픈소스 암호 라이브러리 CIRCL을 훑어 실제 버그 7개를 찾아 고침
- 규모가 꽤 크다 — 암호 프로젝트 200개+ 스캔, 후보 findings 1,000건+ 생성, 그중 CIRCL에서 7개를 진짜로 확정. 전부 Cloudflare 버그 바운티로 보상받음
- 주력 모델은 Claude Opus 4.6과 GPT-5.3. 몇 주 뒤 상위 모델(Opus 4.7·GPT-5.4)로 재스캔하니 어느 모델이 뭘 잡는지가 뒤바뀜 — 모델 성능은 계속 움직인다
- 핵심 교훈 — AI는 진짜 취약점을 짚지만 심각도를 과대·과소평가하고, 독립적인 두 버그를 엉뚱하게 묶는다. 사람 검증이 여전히 필수
어떻게 했나 — 방법론
zkSecurity는 CIRCL을 대상으로 AI 감사 파이프라인을 두 구성으로 돌렸다. 하나는 단순 프롬프트만 준 LLM, 다른 하나는 전문가가 유지관리하는 “skills”를 얹은 LLM이다. 주로 Claude Opus 4.6과 GPT-5.3을 썼고 마지막엔 자체 개발한 zkao 자동 감사 도구를 배포했다. zkao는 “버그를 찾고 고칠 때까지 계속 돌리는 퍼징(fuzzing)처럼” 지속 실행되도록 설계됐다.
전체 규모는 암호 프로젝트 200개+ 스캔, 후보 findings 1,000건+ 생성. 이 중 CIRCL에서 7개를 실제 버그로 확정했다.
찾은 버그 7개
AI 심각도는 모델이 매긴 등급, CF 심각도는 Cloudflare가 최종 판정한 등급이다. 둘의 차이가 이 글의 관전 포인트다.
| # | 버그 | AI 심각도 | CF 심각도 | 원인 |
|---|---|---|---|---|
| 1 | TSS/RSA에서 float64 정밀도 손실 | Critical | Low | math.Pow로 2^53 초과 값 계산 |
| 2 | DLEQ 증명 위조(prover가 SecParam 제어) | High | Low | 검증자가 증명 구조에서 보안 파라미터를 읽음 |
| 3 | BLS 집계 검증에 메시지 고유성 부재 | Medium | High | 중복 메시지 미확인 → rogue key 공격 |
| 4 | DLEQ 건전성 파괴(FillBytes 부호 충돌) | High | Low | 음수 처리에서 암호학적 취약점 |
| 5 | HPKE PSK 검증 우회 | Medium | Medium | Go의 case 구문 오용(비트 OR) |
| 6 | TSS/RSA Lagrange 계수 int64 오버플로우 | High | Medium | 약 21개 플레이어에서 오버플로우 |
| 7 | CP-ABE 접근 제어 파괴(AND-share 버그) | Critical | Critical | AND 게이트에서 랜덤 share 폐기 |
math.Pow로 암호 연산을 하다 부동소수점 정밀도가 깨진 1번, Go의 비트 OR를 논리 OR처럼 오용한 5번처럼, 언어 함정에서 온 버그가 눈에 띈다.
AI 감사의 한계 — 세 가지 패턴
- 심각도 비대칭 — 대부분은 AI가 영향도를 과대평가했다. 반대로 BLS 버그(널리 알려진 rogue key 공격)는 과소평가했는데, “호출자가 알아서 처리해야 한다”는 논리로 완화 요소로 본 듯하다.
- 모델 역할의 변동성 — 초기엔 Opus 4.6이 5개, GPT-5.3이 1개를 찾았으나 상위 모델로 재스캔하자 역할이 역전됐다. 특정 모델이 특정 버그에 강하다고 못 박기 어렵다.
- 독립 문제의 미연결 — 6번처럼 오버플로우와 정수 절단이라는 완전히 독립적인 두 버그를 한 findings로 묶으면서 둘의 관계는 설명하지 않는다.
종합
AI는 프로덕션 암호 코드에서 진짜 취약점을 찾아낼 수 있다는 게 이 사례로 확인됐다. 다만 후보 1,000건에서 7개를 골라내고 심각도를 바로잡는 일은 사람 몫이었다. 저자의 표현대로 “AI 후보는 싸지만 믿을 만한 리포트는 비싸다” — human-in-the-loop이 왜 아직 핵심인지를 숫자로 보여준다.
Loading comments...