GoFetch: 데이터 메모리 의존 프리페처를 이용한 새로운 사이드 채널 공격

 (gofetch.fail)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 데이터 메모리 의존 프리페처(DMP) 가 암호 코드의 데이터 값을 주소처럼 다루면서, 상수 시간(constant-time) 구현에서도 비밀 키가 새어 나갈 수 있음
  • Apple m-series CPU에서는 메모리에서 로드된 값이 포인터처럼 보일 때 DMP가 역참조를 시도해 데이터와 주소 분리라는 상수 시간 프로그래밍 전제가 흔들림
  • 연구진은 Apple m1에서 OpenSSL Diffie-Hellman, Go RSA 복호화, CRYSTALS-Kyber, CRYSTALS-Dilithium의 엔드투엔드 키 추출을 시연했고 m2·m3에서도 유사한 DMP 동작을 확인함
  • m3에서는 DIT bit가 DMP를 효과적으로 비활성화하지만 m1·m2에는 해당하지 않으며, 2024년 4월 발견된 HID 설정 비트는 macOS 커널 지원이 없어 바로 쓰기 어려움
  • 완화에는 최신 소프트웨어 유지, 일부 CPU의 DIT/DOIT bit 사용, 입력 블라인딩, 하드웨어 공유 회피가 포함되며 취약성 평가는 암호분석과 코드 검사가 필요함

GoFetch 공격의 핵심

  • GoFetch는 데이터 메모리 의존 프리페처(DMP)를 이용하는 마이크로아키텍처 사이드 채널 공격임
  • 상수 시간으로 작성된 암호 구현에서도 비밀 키 추출이 가능함
  • 연구진이 시연한 대상은 다음과 같음
    • OpenSSL Diffie-Hellman Key Exchange
    • Go RSA decryption
    • CRYSTALS-Kyber
    • CRYSTALS-Dilithium
  • 논문과 도구는 각각 Paper, Tools로 제공됨

DMP가 상수 시간 전제를 깨는 방식

  • Apple m-series CPU의 DMP는 메모리에서 로드된 데이터가 포인터처럼 보이는 값이면 활성화되고 역참조를 시도함
  • 상수 시간 프로그래밍은 비밀 값에 따라 분기, 루프, 메모리 접근, 배열 인덱스가 달라지지 않도록 데이터와 주소를 분리해야 함
  • 피해자 코드가 이 규칙을 지켜도, DMP가 하드웨어 수준에서 비밀 의존적 메모리 접근을 대신 만들어낼 수 있음
  • 그 결과 원래 상수 시간이어야 하는 코드에 관측 가능한 시간 차이가 생기고 키 추출 공격에 노출됨

공격 절차

  • 공격자는 암호 연산에 들어가는 선택 입력을 구성해, 비밀 키 일부를 맞게 추측했을 때만 중간 상태에 포인터처럼 보이는 값이 나타나게 함
  • 이후 캐시 타이밍 분석으로 DMP가 역참조를 수행했는지 확인해 추측이 맞는지 검증함
  • 올바른 추측이 확인되면 같은 방식으로 다음 키 비트 묶음을 추측함
  • 이 절차로 고전 암호와 포스트퀀텀 암호 구현에서 엔드투엔드 키 추출이 가능함

영향받는 프로세서와 관찰 결과

  • 엔드투엔드 GoFetch 공격은 Apple m1 프로세서가 장착된 하드웨어에서 수행됨
  • m2와 m3 CPU도 유사하게 악용 가능한 DMP 활성화 패턴을 보임
  • m2 Pro 같은 다른 m-series 변형은 테스트하지 않았지만, 단순 모델과 같은 마이크로아키텍처를 쓰므로 악용 가능한 DMP가 있을 가능성이 있음
  • Intel 13th Gen Raptor Lake 마이크로아키텍처에도 DMP가 있음
    • 다만 활성화 기준이 더 제한적이어서 GoFetch 공격에는 견고함

Augury와의 차이

  • Apple m-series DMP는 Augury가 처음 발견함
  • Augury는 DMP가 일부 조건에서 데이터와 주소를 섞을 수 있다고 봄
  • GoFetch 연구진은 Augury가 정리한 DMP 활성화 기준이 지나치게 제한적이라고 판단함
  • 실제 동작에서는 메모리에서 로드된 어떤 값도 역참조 후보가 될 수 있어, 실제 상수 시간 암호 코드에 대한 엔드투엔드 공격으로 이어짐

캐시와 프리페처 배경

  • 최신 프로세서는 메모리 접근 지연을 줄이기 위해 캐시를 사용함
  • 이전에 접근한 데이터는 캐시에 남아 이후 접근이 더 빨라짐
  • 같은 머신에서 함께 실행되는 공격자는 공유 캐시 상태를 관찰해 피해자의 접근 패턴을 추론할 수 있음
  • 일반 프리페처는 이전 메모리 접근 주소 추적을 바탕으로 앞으로 접근할 주소를 예측함
  • DMP는 연결 리스트 순회 같은 불규칙 접근 패턴을 처리하기 위해 메모리 내용까지 고려해 가져올 데이터를 결정함
  • 이 동작은 하드웨어 수준에서 데이터와 메모리 주소를 섞기 때문에 전체 계산 스택을 비상수 시간(non-constant-time)처럼 만들 수 있음

취약 여부 판단과 완화책

  • 구현이 취약한지 판단하려면 중간 값이 비밀 의존적으로 포인터처럼 보이게 만들 수 있는 시점과 방식을 알아야 함
  • 이 평가는 암호분석과 코드 검사가 필요하며, 수작업이고 느린 데다 다른 공격 방식을 배제하지 못함
  • 일부 프로세서에서는 DMP를 비활성화할 수 있음
    • m3 CPU에서는 DIT bit 설정이 DMP를 효과적으로 비활성화함
    • m1과 m2에는 해당하지 않음
    • Intel Raptor Lake에서는 DOIT bit로 DMP를 비활성화할 수 있음
  • 2024년 4월 Hector Martin(marcan)이 m1·m2 CPU에서 DMP를 비활성화하는 HID 설정 비트 SYS_APL_HID11_EL1[30]을 발견함
    • 이 chicken bit 설정에는 커널 지원이 필요함
    • 현재 macOS에는 해당 지원이 없음
    • 관련 정보는 @marcan의 글에 있음
  • 사용자에게는 최신 소프트웨어 사용과 정기 업데이트가 권장됨
  • 암호 라이브러리 개발자는 가능한 CPU에서 DIT/DOIT bit를 설정할 수 있음
  • 입력 블라인딩은 일부 암호 스킴에서 공격자가 제어하는 중간 값을 피하는 데 도움이 될 수 있음
  • 공격자가 DMP 활성화를 측정하지 못하도록 하드웨어 공유를 피하면 암호 프로토콜 보안을 더 강화할 수 있음

공개와 후속 업데이트

  • 연구진은 2023년 12월 5일 Apple에 결과를 공개했으며, 이는 공개 릴리스 107일 전임
  • 2024년 8월 GoFetch는 Pwnie Award 2024 Best Cryptographic Attack을 수상함
  • 2024년 12월 후속 연구에서 Intel DMP의 의미론을 리버스 엔지니어링하고, DMP가 유효하지 않은 포인터를 역참조하는 경우에도 정보를 유출할 수 있는 기법을 보임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 효율 코어 같은 게 들어가는 시대라면, 현대 아키텍처에 암호화 코어도 필요할 수 있겠음
    이런 코어는 상수 시간 알고리즘과 관련된 보장을 명시적으로 제공하고, 선가져오기나 분기 예측 등을 하지 않는 식이어야 함
    Itanium 비슷하지만 “암호화 프로세서”로 한정된 형태라면, 빠지는 기능이 많으니 원칙적으로 코어 자체의 실리콘 면적도 크지 않을 듯함
    암호화 코드를 구현하는 입장이라면 이런 문제는 술이 당길 정도로 힘들 것 같음. 최선의 상황에서도 어려운 싸움인데, 다 맞게 구현해도 현재와 미래의 수많은 프로세서 기능이 언제든 코드를 깨뜨릴 수 있음

    • 암호화 구현자 입장에서 보면, 이런 문제들은 정말 미치게 만듦
      하지만 암호화 보조 프로세서는 너무 파괴적인 해법임. 해당 코어로 전환하고 돌아오고, 메모리를 공유하는 등의 기반 구조를 산더미처럼 만들어야 함
      더 심각한 건 RSA 곱셈만 그 코어로 옮기고 끝낼 수 없다는 점임. 키는 어딘가에서 파싱됐을 텐데, 파서도 암호화 코어에서 돌아야 하나? 네트워크로 들어오면 어떡하나? 키를 전부 보호해도 CPU 부채널이 암호화한 메시지를 유출하면 괜찮은가? 키가 아니라서 괜찮다고 볼 수 있나?
      비암호화 코드에서 이런 공격이 잘 안 보이는 이유는 표적을 찾는 일이 애플리케이션별로 너무 다르기 때문이고, 암호화 라이브러리에서는 모두가 키 유출은 나쁘다는 데 동의하기 때문임
      결국 프로세서 설계자들이 가정을 깨지 말아야 하고, 적어도 그러기 전에 우리와 이야기해야 함
    • 더 가능성 높은 방향은 실행 코드의 특정 구간에서 CPU의 이런 구성요소를 끌 수 있는 모드 전환일 듯함
      추상화 단위는 아마 스레드 수준이 될 가능성이 큼
    • 그게 Secure Enclave의 존재 이유 아닌가?
      https://support.apple.com/guide/security/secure-enclave-sec5...
    • 암호화된 버스 MMU는 1990년대부터 있었음
      하지만 비용 최적화된 클라우드 아키텍처가 소비자용 하드웨어로 쏠리면서 CPU 시장을 먹어버렸고, 이제 대규모 애플리케이션에서도 현실적인 선택지는 소비자용 CPU뿐임
    • 많은 현대 아키텍처에는 보통 몇 가지 흔한 알고리즘을 가속하는 암호화 확장이 있음
      새 알고리즘을 가능하게 하려면 몇 가지 암호화 기본 연산 명령을 추가하는 것도 좋을 수 있음

  • 논문에 따르면 “OpenSSL은 로컬 부채널 공격이 위협 모델 밖에 있다고 보고했고, Go Crypto 팀은 이 공격의 심각도를 낮게 본다”고 함

  • 이런 부채널 공격의 최종 결론은 아무 최적화도 하지 않고, 모든 명령어가 모든 상황에서 같은 사이클 수로 실행되는 CPU일 것임
    하지만 그런 일은 절대 없을 것임. 느린 CPU를 원하는 사람은 없음
    원격으로 악용될 수 없다면 걱정할 문제는 아니라고 봄. 물론 다중 임차 클라우드 가상화는 안 됨

    • 신뢰할 수 없는 코드는 전부 끔찍한 순차 실행 코어에 던져야 함
      추측 실행도 없고, 선가져오기도 없고, 컴퓨터 아키텍처 101 수업에 나오는 5단계 파이프라인 같은 코어 말임
    • “다중 임차 클라우드 가상화” 때문에, 몇 년 전 Intel 칩의 같은 취약점만큼은 걱정하지 않음
      랙마운트 Mac Mini의 연산 시간을 빌려주는 클라우드 사업자들이 조금 있긴 하지만 많지 않고, 그마저도 매우 특정한 워크로드나 빌드 작업용임
      그런 서비스에 큰돈을 내는 사람들에겐 문제일 수 있겠지만, Apple Silicon 기기의 압도적 다수는 절대로 클라우드 서비스를 호스팅하지 않을 것임
    • 그래서 많은 코어 수와 격리가 중요함
      코드를 특정 코어에 격리하면, 모든 것이 의도대로 동작한다는 전제에서 익스플로잇이 다른 임차자를 침해하지 못함

  • “DMP를 비활성화할 수 있나?”에 대해 “그렇지만 일부 프로세서에서만 가능하다. M3 CPU에서는 DIT 비트 설정이 DMP를 효과적으로 비활성화하지만, M1과 M2에서는 그렇지 않다”고 되어 있음
    분명 어딘가에 이걸 끄는 치킨 비트가 있지 않을까?

    • 이런 비트들은 어떻게 설정하는지 늘 궁금했음
      Swift에서 할 수 있는 건가, 아니면 어셈블리가 필요한가?

  • 읽어보니 libsodium 같은 라이브러리는 M3 이상에서 민감한 암호화 연산 전에 비활성화 비트를 설정하면 될 것 같음
    또한 키의 일부 측면을 미리 알아내야 하는 것으로 보임
    아주 멋지지만, 딱히 실용적으로 보이진 않음

  • 2022년의 Augury 공격이 떠올랐음. 이것도 Apple Silicon CPU의 DMP 선가져오기를 악용했음
    [1]: https://www.prefetchers.info

    • 참고로 GoFetch 저자 중 세 명은 Augury에도 참여했음
    • 맞음, 글과 FAQ에서 그걸 구체적으로 언급함

  • Apple에는 왜 이렇게 하드웨어 백도… 순수한 버그가 많을까?

    • 애초에 캐시는 왜 필요하지? 선가져오기는 왜 필요하지?
      그 헛소리 같은 백도어 음모론에 답하자면, 사람들은 빠른 CPU를 원하기 때문에 프로세서에는 캐시와 시간 차이가 있음. 상수 시간과 빠른 성능을 동시에 가질 수는 없고, Apple만 선가져오기를 가진 회사도 아님
      여기 Apple이 암호화를 위해 상수 시간 연산을 켜는 방법을 문서화해 둔 자료가 있음. 마치 하드웨어에 의도적으로 설계된 것처럼 보이네. 참 이상하지: https://developer.apple.com/documentation/xcode/writing-arm6...
    • Intel과 AMD에 Meltdown과 Spectre가 있었던 것과 같은 이유임

  • 암호화 루틴을 작성한다면 플랫폼 암호화 라이브러리를 쓰거나, 문서를 따라야 함
    https://developer.apple.com/documentation/xcode/writing-arm6...

  • 이제 Mac과 iPad에서도 악성코드 검사와 바이러스 스캐너가 의미 있어졌음
    공격자는 같은 하드웨어에서 실행 중이어야 함

답변달기