시그널 암호 코드 보안을 AI가 증명한 AlphaProof Code
사람이 '무엇을 증명할지'를 정하면 AI 에이전트 팀이 증명을 쓰는 방식으로, 메신저 시그널의 암호 코드가 보안 약속을 지킨다는 것을 기계 검산으로 보였다.
쉽게 말하면비유하자면 수학 시험에서 답안은 AI 수십 명이 쓰고, 채점은 절대 봐주지 않는 기계 채점기가 한다. 사람은 문제지가 제대로 된 문제인지만 꼼꼼히 본다. 답안이 650만 줄이어도 채점기가 한 줄씩 검산하니, AI가 실수하면 통과하지 못한다. 다만 문제지가 엉성하면 만점의 값어치도 그만큼 떨어진다. 이 약점은 실제 연구에도 그대로 남아 있다.
- 예를 들면
- 연구진은 시그널 코드에서 이미 고쳐진 실제 버그 두 개를 일부러 되살려 다시 프로그램을 만들었다. 그러자 두 경우 모두 '이 프로그램은 보안 정리를 지키지 못한다'는 증명이 나왔다. 명세가 진짜 버그를 걸러낼 만큼 촘촘한지 확인한 실험이다.
- 왜 봐야 하나
- 시그널 방식 암호화는 왓츠앱, 구글 메시지에도 쓰인다. 코드 한 군데만 틀려도 많은 사람의 대화가 드러날 수 있다. AI가 쓴 결과를 '그럴듯하다'가 아니라 기계 검산으로 확인하는 길이 실제 제품 코드에서도 통할 수 있음을 보여 준다.
알아낸 것
- 에이전트가 쓴 Lean 증명은 약 650만 줄이다. 사람이 직접 읽고 믿어야 하는 것은 명세와 '프로세서가 명령을 어떻게 실행하는지 적은 규칙'을 합쳐 약 2만 6천 줄로, 증명 분량의 1%에 못 미친다.
- 연구진 5명이 4주 동안 작업했고, 증명 코드는 사람이 한 줄도 쓰지 않았다. 저자들은 과거 사례로 운영체제 핵심부 seL4 검증에 20인년이 들었다고 든다. 다만 seL4는 다른 프로그램이라 같은 일을 놓고 잰 비교는 아니다.
- 증명 대상은 설계도가 아니라 컴파일된 실행 파일이다. 손대지 않은 시그널 코드를 보통 컴파일러로 시험용 프로그램에 담아 만든 기계어 명령 약 14만 개를 하나하나 따라갔다. 가정으로 처리한 루틴 39개는 여기서 빠진다.
- 이미 고쳐진 버그 2개를 되살린 실행 파일에서는 2개 모두 '안전하지 않다'는 증명이 나왔다. 명세를 맞추다가 기존 분석 논문 한 편에서 빈틈과 오류 15건도 찾았다.
한계와 주의할 점
- 검증한 것은 시그널 앱이 아니라 시그널 코드(libsignal)를 감싼 시험용 명령줄 프로그램이다. 1대1 대화만 다뤘고 단체 대화, 여러 기기 사용, 열쇠 생성 단계는 빠졌다.
- 밑바닥 암호 연산을 포함한 루틴 39개는 증명하지 않고 '정해진 대로 동작한다'고 가정했다. 양자컴퓨터 공격자에 대한 보장은 첫 열쇠 교환의 비밀성 등 일부뿐이다. 확률로 따진 보장은 규모가 커지면 의미가 없어진다. 저자들에 따르면 거의 모든 메시지가 새 에포크(열쇠를 새로 교환하는 구간)를 여는 경우, 한 대화에서 메시지 약 2만 5천 개, 또는 메시지 약 1천 개짜리 대화 약 100만 개가 그 한계다.
- 명세에 빈틈이 있으면 증명이 통과해도 보장이 약해지는데, 명세가 옳은지는 사람 검토에 기댄다. 이 글은 딥마인드가 직접 낸 블로그와 기술 보고서이고, 동료 심사를 거쳤다는 표시는 원문에 없다. 명세와 증명은 공개했다고 적혀 있다.
용어 풀이
- 형식 검증(formal verification)
- 프로그램이 지켜야 할 성질을 수학 문장으로 적고, 프로그램이 그 성질을 항상 지킨다는 것을 증명하는 일이다. 몇 번 돌려 보는 테스트와 달리 모든 경우를 다룬다.
- Lean
- 수학 증명을 컴퓨터가 한 줄씩 검산해 주는 언어이자 프로그램이다. 틀린 증명은 통과하지 못한다.
- 명세(specification)
- '무엇을 증명할지'를 적은 문서다. 여기서는 '안전하다'가 정확히 무슨 뜻인지 정한 Lean 문장들을 가리킨다.
- 순방향 비밀성·침해 후 보안(forward secrecy, post-compromise security)
- 앞의 것은 지금 열쇠를 도둑맞아도 예전 대화는 읽지 못하게 하는 성질이다. 뒤의 것은 도둑맞은 뒤에도 새 열쇠 교환이 이뤄지면 다시 안전해지는 성질이다.
더 깊이 읽기 읽는 데 약 3분
무엇이 문제였나
소프트웨어가 안전한지는 보통 테스트와 코드 검토로 확인한다. 그러나 테스트는 해 본 경우만 알려 준다. 형식 검증(formal verification)은 '이 프로그램은 이 성질을 항상 지킨다'를 수학으로 증명한다. 문제는 품이다. 저자들은 운영체제 핵심부 seL4 검증에 20인년, C 컴파일러 CompCert 검증에 6인년이 들었다고 적는다. 둘 다 처음부터 검증하기 쉽게 쓴 코드였다.
시그널 프로토콜의 '설계'는 그동안 여러 번 증명됐다. 하지만 실제 버그는 설계와 구현 사이 틈에서 자주 생긴다. 구현 코드는 순서가 뒤바뀌어 도착하는 메시지를 풀 열쇠 보관, 예전 세션 보관, 데이터 포장 같은 일을 훨씬 많이 하기 때문이다. 저자들은 널리 쓰이는 암호 프로토콜의 손대지 않은 실제 코드에 프로토콜 수준 보안을 증명한 것은 이번이 처음이라고 주장한다.
어떻게 했나
일을 둘로 나눴다. '무엇을 증명할지'를 적는 명세(specification)는 사람이 이끈다. 명세 작성 에이전트가 기존 논문의 보안 정의를 Lean 문장으로 옮기고, 다른 모델 계열의 검토 에이전트가 허점을 찾고, 사람이 고쳐서 승인한다. 이 단계에는 Gemini 4 Carbon과 Claude Opus 5.5가 쓰였다. 승인된 명세는 에이전트가 손댈 수 없는 곳에 따로 보관한다.
증명 쓰기는 Gemini 4 Carbon 기반 에이전트가 보통 40~80개씩 한 팀을 이뤄 맡았다. 일을 나누는 조율자, 중간 팀장, 작업자, 증명 구조를 짜는 설계자가 있다. 한 번의 작업은 보통 컴퓨터 한 대에서 24~72시간 돌았다. 마지막 관문은 문지기(gatekeeper)다. Lean에서 증명을 최종 검산하는 작은 핵심 프로그램(커널)이 증명을 통과시키고, 증명한 문장이 보관해 둔 명세와 똑같을 때만 완료로 인정한다. 에이전트가 '다 했다'고 보고해도 그 말은 믿지 않는다.
AI가 문제를 슬쩍 쉽게 바꾸지 못하게 한 장치
저자들은 에이전트가 목표를 끝내라는 압박을 받으면 문제를 슬쩍 쉽게 바꾸기도 한다고 적는다. 그래서 명세를 고치려면 증명 과정을 보지 못하는 비평 에이전트의 심사를 거쳐야 한다. 보안을 약하게 만드는 수정은 받아들이지 않고, 사람에게 '코드 버그일 수 있다'고 올린다. 또 코드에 일부러 버그를 심어 보안 정리가 깨지는지 보는 방법으로 명세가 느슨하지 않은지 시험했다.
결과와 숫자의 뜻
저장소 전체는 약 700만 줄이고 그 가운데 약 650만 줄이 증명이다. 530만 줄은 기계어가 모델대로 움직인다는 증명이고, 나머지가 두 가지 보안 증명이다. 사람이 읽고 믿어야 하는 부분은 명세 약 1만 8천 줄과 프로세서 동작 규칙 약 8천 줄이다. 증명이 아무리 길어도 Lean이 검산하므로 사람은 이 짧은 부분만 꼼꼼히 보면 된다는 것이 이 방식의 논리다.
증명한 성질은 순방향 비밀성, 침해 후 보안, 상대방 인증, 첫 열쇠 교환의 비밀성이다. 두 가지 표준 방식으로 따로 증명했다. 암호 부품을 완벽한 블랙박스로 보는 기호 모델에서는 정리 10개를 얻었다. 공격자의 성공 확률을 따지는 계산 모델에서는 확률 상한 하나를 얻었다. 되살린 버그 2개가 '안전하지 않다'고 증명된 곳은 기호 모델 쪽이다. 계산 모델 쪽 반증은 훨씬 어렵다고 저자들은 밝힌다.
쓸모와 주의할 점
저자들이 꼽는 교훈은 증명이 싸지면 어려운 일이 '무엇을 증명할지'로 옮겨 간다는 것이다. 실제로 품의 대부분이 명세에 들어갔다고 한다. 명세에 빈틈이 있으면 증명이 통과해도 보장은 그만큼 약해진다. 그리고 명세가 옳은지는 기계가 대신 확인해 주지 못한다. 저자들은 이런 명세가 자리 잡으려면 열린 검토를 여러 번 거쳐야 한다고 보고, 명세와 증명을 모두 공개한다고 밝혔다.
보장 범위도 좁게 읽어야 한다. 대상은 시그널 앱이 아니라 시그널 코드를 감싼 시험용 프로그램이다. 밑바닥 암호 연산을 포함한 루틴 39개는 '정해진 대로 동작한다'는 가정으로 처리했다. 단체 대화와 여러 기기 사용은 빠졌다. 의료기기나 전력망 소프트웨어로 넓힐 수 있다는 말은 블로그가 내놓은 전망이지 이번에 보인 결과가 아니다.
원문에서 확인한 근거 5곳
- 에이전트가 쓴 증명은 약 650만 줄이고, 사람이 믿어야 하는 명세와 프로세서 동작 규칙은 약 2만 6천 줄이다.기술 보고서 초록, 1절 끝, 7절 'Scale' 문단
- 5명이 4주 동안 작업했고 증명 코드는 사람이 쓰지 않았다. 에이전트 팀은 보통 40~80개 규모로 24~72시간씩 돌았다.기술 보고서 7절 첫 문단과 'Generating proofs' 문단, 2.3절
- 이미 고쳐진 버그 2개를 되살린 실행 파일은 둘 다 기호 모델 보안 정리를 어긴다는 증명이 나왔다.기술 보고서 6절 'Finding Historical Bugs', 블로그 본문
- 증명은 Lean 커널 검사와 보관해 둔 명세와의 일치 확인을 모두 통과해야 인정된다. 명세 수정은 따로 심사한다.기술 보고서 그림 1, 2.3절, 2.4절, 7절 'Preventing specification weakening' 문단
- 보장 범위는 1대1 대화, 시험용 프로그램, 가정으로 처리한 암호 연산으로 한정된다. 확률 상한은 규모가 커지면 의미가 없어진다.기술 보고서 표 1, 4절, 5.1.6절, 5.2.5절, 부록 B.7·C.6
11월 13일(금) 11:31 정리 · AI가 쓰고 원문과 대조
AI 목록