요즘.zip
공식 연구 발표난이도 어려움Google DeepMind · 11월 10일(화) 공개

시그널 암호 코드 보안을 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 목록

다른 AI 글

전체 보기
물리 연구를 통째로 맡겨 보는 AI 시험 FrontierPhysics물리학자 42명이 자기 연구로 만든 과제 56개를 AI 에이전트에게 통째로 맡겼더니, 가장 잘한 AI도 168번 가운데 46…평가·벤치마크난이도 보통AI가 아는 것과 '안다'는 말의 차이를 잰 벤치마크 FinDendro날짜가 붙은 미국 금융 사실 2,226건으로 AI가 실제로 맞히는 것과 '안다'고 말하는 것을 견줬더니, 대부분의 모델에서…평가·벤치마크난이도 보통에이전트 메모에 근거 기록을 연결하는 기억 기법 WikiTraceAI 에이전트가 쌓아 둔 교훈마다 근거가 된 작업 기록을 연결해 되짚게 했더니, 메모 때문에 틀리는 일이 줄고 평균 점수가…연구 · 프리프린트난이도 보통세포 종류별로 DNA 변이 영향을 예측하는 알파게놈 2DNA 100만 글자와 '어떤 세포인지'를 함께 넣는 모델을 만들어, 변이가 세포 종류마다 유전자 활동을 어떻게 바꾸는지 이…공식 연구 발표난이도 어려움AI 모델 파일에 남은 GPU 지문을 읽는 체크포인트 포렌식공개된 AI 모델 파일에 남은 초기값 흔적으로 첫 값을 만든 GPU 계열을 가려내는 방법을 내놓았다. 중국 4개 회사의 모델…기술 보고서난이도 어려움생활 속 일을 실제로 해내는 AI를 평가하는 LifeVal시간 사용 조사와 이용자 설문으로 생활 과제를 정한 평가이며, 공개된 일부 과제 점수의 의미와 한계를 살펴봅니다.평가난이도 쉬움잡음을 지웠더니 언어 판별이 나빠졌다: SceneMaker의 한국어 방송 실험한국어 방송 6편의 발화 3,115구간에서 잡음 제거가 언어 판별 점수를 낮춘 사례를 살펴보고, 검수 방식과 적용 범위를 구…커뮤니티 해설난이도 보통한국어 받아쓰기·화자 구분을 한 모델로: Nemotron 3.5 Transcribe하나의 음성 모델로 받아쓰기·화자 구분·번역을 처리하며, 한국어 성능과 녹음 처리 속도의 평가 조건을 살펴봅니다.커뮤니티 해설난이도 보통