1P by GN⁺ | ★ favorite | 댓글 1개
  • LTESniffer는 LTE 기지국과 스마트폰 사이의 다운링크·업링크 무선 메시지를 캡처하고, PDCCH에서 DCI와 RNTI를 먼저 얻은 뒤 PDSCH·PUSCH를 디코딩해 데이터 트래픽을 분석하는 오픈소스 도구임
  • 암호화된 메시지를 복호화할 수 없으며, MAC·물리 계층 헤더처럼 암호화되지 않은 부분이나 기지국 브로드캐스트 메시지, 연결 초기 평문 메시지만 분석 가능함
  • 보안 연구용 API는 identity mapping, IMSI collecting, UE capability profiling 3가지를 지원하며, 기존 LTE 보안 연구가 가정한 수동 스니퍼 요구를 PDSCH·PUSCH 프로토콜 패킷 디코딩으로 보완하려는 구현임
  • 기능 범위는 LTE Advanced·LTE Advanced Pro, 업링크·다운링크 최대 256QAM, FDD, 최대 20MHz 기지국, DCI formats 0/1A/1/1B/1C/2/2A/2B, transmission modes 1~4를 포함함
  • 실시간 디코딩에는 다중 물리 코어 CPU와 SDR 구성이 필요하며, 업링크 트래픽 수집은 UE 신호가 약해 스니퍼가 스마트폰 가까이에 있거나 지향성 안테나·RF 프론트엔드·증폭기 같은 하드웨어 보강이 필요함

LTESniffer가 하는 일

  • LTESniffer는 LTE 다운링크와 업링크를 모두 캡처하는 오픈소스 도청기임
  • 동작 흐름은 먼저 PDCCH를 디코딩해 활성 사용자들의 DCI와 RNTI를 얻고, 이를 사용해 PDSCH와 PUSCH를 추가로 디코딩해 업링크·다운링크 데이터 트래픽을 가져오는 방식임
  • 일반 사용자 관점에서는 기지국과 연결된 스마트폰 사이에서 오가는 LTE 무선 메시지를 양방향으로 캡처하는 도구임
  • 암호화된 메시지는 복호화할 수 없음
    • 암호화된 메시지에서는 MAC·물리 계층 헤더처럼 암호화되지 않은 부분을 분석할 수 있음
    • 평문으로 전송되는 기지국 브로드캐스트 메시지나 연결 초기 메시지는 완전히 분석 가능함

보안 연구 API와 연구 목적

  • LTESniffer는 보안 애플리케이션과 연구를 위한 3개 API 기능을 제공함
    • identity mapping
    • IMSI collecting
    • UE capability profiling
  • 많은 LTE 보안 연구는 공중에서 프라이버시 관련 패킷을 캡처할 수 있는 수동 스니퍼를 가정하지만, 기존 오픈소스 스니퍼들은 PDSCH와 PUSCH의 프로토콜 패킷을 디코딩하지 못해 요구사항을 충족하지 못한다고 밝힘
  • 자세한 내용은 논문에 정리돼 있음
  • LTESniffer의 주된 목적은 셀룰러 네트워크 보안·분석 연구 지원임
    • 업링크·다운링크 사용자 데이터를 수집하므로 LTE 트래픽 스니핑에 관한 현지 규정을 따라야 함
    • 사용자 프라이버시 관련 정보를 의도적으로 수집하는 등 불법 목적 사용에 대해 개발자는 책임지지 않음

지원 기능과 구현 기반

  • LTESniffer는 FALCON 위에 구현됐고, srsRAN 라이브러리를 사용함
  • 주요 지원 범위는 다음과 같음
    • PDCCH, PDSCH, PUSCH 제어·데이터 채널의 실시간 업링크·다운링크 디코딩
    • LTE Advanced와 LTE Advanced Pro
    • 업링크·다운링크 모두 최대 256QAM
    • DCI formats 0, 1A, 1, 1B, 1C, 2, 2A, 2B
    • transmission modes 1, 2, 3, 4
    • FDD만 지원

      • 최대 20MHz 기지국
      • 스마트폰별 최대 UL/DL 변조 방식 자동 감지
      • UE별 물리 계층 구성 자동 감지
      • RNTI-TMSI mapping, IMSI collecting, UE Capability Profiling
      • v2.1.0 업데이트는 서브프레임 IQ raw data 파일 기록, 기록 파일을 이용한 오프라인 디코딩, 다운링크 모드의 API 활성화를 추가함
      • 다운링크 모드 API는 identity collecting과 mapping API에만 적용됨
      • 관련 내용은 LTESniffer-record-subframe 브랜치와 README에 있음
      • v2.0.0 업데이트는 업링크 스니핑 모드에서 두 대의 USRP B-series 사용을 지원하고 버그를 수정함
      • 관련 내용은 LTESniffer-multi-usrp 브랜치와 README에 있음

하드웨어·소프트웨어 요구사항

  • 안정 동작 OS는 Ubuntu 18.04/20.04/22.04
  • 실시간 LTE 트래픽 디코딩은 기지국에 활성 사용자가 많은 피크 시간대에 다중 물리 코어를 가진 고성능 CPU가 필요함
    • Intel i7-9700K PC에서 활성 사용자 150명의 기지국 트래픽을 실시간 디코딩한 사례가 있음
    • 권장 사양은 8개 이상 물리 코어의 Intel i7 CPU, 16GB 이상 RAM, 256GB SSD임
  • 다운링크만 스니핑할 때는 srsRAN이 지원하는 대부분의 SDR을 사용할 수 있음
    • 예시는 USRP 또는 BladeRF임
    • SDR은 USB 3.0으로 PC에 연결돼야 함
    • transmission modes 3·4 다운링크 메시지를 디코딩하려면 RX 안테나 2개가 필요함
    • RX 안테나가 1개뿐이면 transmission mode 1 다운링크 메시지만 디코딩함
    • GPSDO는 다운링크 스니핑에서 동기화 개선에는 도움이 되지만 필수는 아님
  • 업링크 스니핑은 업링크와 다운링크 두 주파수를 동시에 들어야 하므로 두 구성이 지원됨
    • 단일 USRP X310: RX 채널 2개가 서로 다른 업링크·다운링크 주파수에 맞춰질 수 있으며 GPSDO는 선택 사항임
    • 2대의 USRP B-Series: B210/B200을 업링크·다운링크에 각각 사용하고, GPSDO를 clock source와 time reference로 써서 두 USRP를 동기화함
    • 2대의 USRP B-Series 구성에서는 GPSDO가 필수임

설치와 실행 흐름

  • 소스 빌드 전 UHD 4.0 이상 설치가 필요하며, 소스 빌드를 권장함
  • srsRAN 의존성과 LTESniffer 의존성을 설치한 뒤 저장소를 클론하고 cmake, make -j 4로 빌드함
  • 빌드 후 실행 파일은 <build-dir>/src/LTESniffer에 위치함
  • 주요 실행 모드는 3가지임
    • 기지국에서 오는 LTE 다운링크 트래픽 스니핑
    • 스마트폰에서 기지국으로 가는 LTE 업링크 트래픽 스니핑
    • 보안 API
  • 상용망에서 사용하기 전 LTE 트래픽 스니핑에 관한 현지 규정을 확인해야 함
  • 테스트 스마트폰이 연결된 기지국과 업링크·다운링크 대역을 확인하려면 Android용 Cellular-Z를 사용할 수 있음
    • LTESniffer도 같은 셀과 주파수에 연결해야 함

출력과 분석

  • LTESniffer는 출력으로 pcap 파일을 제공하며, Wireshark에서 추가 분석과 패킷 추적을 할 수 있음
  • 생성 파일명은 모드별로 다름
    • 다운링크: sniffer_dl_mode.pcap
    • 업링크: sniffer_ul_mode.pcap
    • API: api_collector.pcap
  • pcap 파일은 LTESniffer가 실행된 동일 디렉터리에 생성됨
  • Wireshark가 디코딩된 패킷을 올바르게 분석하려면 pcap_file_example/README.md의 설정 가이드를 참고해야 함
  • 업링크 pcap 파일에는 업링크와 다운링크 메시지가 모두 포함됨
    • 업링크만 보려면 mac-lte.direction == 0 필터를 사용함
    • 다운링크만 보려면 mac-lte.direction == 1 필터를 사용함

업링크 스니핑의 거리 제약

  • LTESniffer의 업링크 유효 범위는 SDR 같은 RF 프론트엔드 성능 때문에 제한됨
  • UE는 배터리 사용을 최적화하는 휴대기기라 업링크 신호 전력이 기지국 다운링크 신호보다 훨씬 약함
  • 업링크 트래픽을 성공적으로 캡처하려면 다음 방식으로 수신 신호 전력을 높일 수 있음
    • UE에 물리적으로 가까이 위치
    • 지향성 안테나, 전용 RF 프론트엔드, 신호 증폭기 같은 특수 하드웨어 사용

FAQ에서 명시한 제한과 대안

  • GPSDO는 더 안정적인 동기화에 유용하지만, 다운링크 스니핑에서는 GPSDO 없이도 LTE 신호와 동기화해 패킷을 디코딩할 수 있음
  • 업링크 스니핑에서 GPSDO는 2대의 USRP B-series를 사용할 때만 필요함
    • 단일 USRP X310 구성은 GPSDO가 필요하지 않음
  • 다운링크 트래픽은 srsRAN 라이브러리가 지원하는 BladeRF 같은 SDR로도 기술적으로 실행 가능함
    • 다만 LTESniffer 다운링크 기능 테스트는 USRP B210과 X310으로만 수행됨
  • LTESniffer 사용의 적법성은 암호화되지 않은 LTE 트래픽 스니핑에 관한 현지 규정을 확인해야 함
    • 다른 테스트 방법으로는 Faraday cage 안에서 srsRAN 기반 개인 LTE 네트워크를 구성하는 방식이 제시됨
  • 두 사용자 간 메시지 내용은 암호화되지 않은 부분만 볼 수 있음
    • 기지국과 사용자 사이의 무선 트래픽은 대부분 암호화됨
  • LTE 네트워크에는 TMSI, GUTI, IMSI, RNTI처럼 평문으로 노출되는 여러 식별자가 문헌에 나타남

댓글과 토론

Hacker News 의견들
  • 모바일 네트워크 표준은 약어로 가득 차 있어서 좋음
    혹시 몰랐다면 PHICH의 Q는 "request"를 뜻함

    • 위에서 무슨 말을 하는지 궁금한 사람을 위해 설명하면, PHICH는 참조된 프로젝트에 나오지는 않지만 이상한 모바일 네트워크 약어의 예시로, "Physical channel HybridARQ Indicator Channel"의 약자임
      그 안의 "ARQ"는 아마 https://en.wikipedia.org/wiki/Automatic_repeat_request로 풀어 쓸 수 있음
      어떤 사람들은 "ARQ"의 "Q"가 실제로는 "query"라고 할 수도 있고, "request"로 푸는 사람들은 평균적인 어휘 수준을 낮게 보는 것이라고 할 수도 있음
      개인적으로는 생각해 보면 Q가 "request"나 "query"가 아니라, https://en.wikipedia.org/wiki/Q_code에 나오는 관례적인 불투명한 Q 코드의 또 다른 흔적일 가능성이 높다고 봄
    • 농담하는 줄 알았음
      여기 PHICH 안의 Q가 있음: https://github.com/srsran/srsRAN_4G/blob/master/lib/src/phy/...
      형제 댓글처럼 q는 reQuest의 Q임
  • 좋아 보임
    FDD만 지원하고 TDD는 없으며, 20MHz로 제한되어 있어서 제약은 좀 있음
    어느 정도 실시간 디코딩도 가능한 것 같아 흥미로움. 기지국에서는 처리의 큰 부분을 꽤 범용적인 프로세서가 맡지만, 그래도 이 소프트웨어보다 하드웨어와 훨씬 더 긴밀하게 통합되어 있음

  • 이걸 돌릴 하드웨어가 너무 비싸서 아쉬움 :'(

  • 약간 곁가지지만, DSL 도청을 시도해 본 사람이 있는지 궁금함
    현대 DSL, 특히 VDSL2는 본질적으로 차폐되지 않은 꼬임쌍선 위를 따라가는 고주파 신호라서 선로 분기 같은 것까지 있으면 쉽게 새어 나와 방사될 것임
    실제로 영국의 아마추어 무선사들이 이에 대해 많이 불평할 정도로 그런 듯함[1]. 그 신호를 여전히 복조할 수 있는지, 아니면 스펙트럼에서 성가신 기준 잡음일 뿐인지 궁금함
    [1]: https://rsgb.services/public/publications/vdsl/measuring_and...

  • 덜 알려진 흥미로운 사실은, 초기 디지털 휴대전화 세대들이 해독 난이도의 애매한 지점에 있다는 것임
    전혀 쉽지는 않지만, 깨뜨릴 수 있을 만큼은 쉬움. 암호화가 실제로 깨짐
    무지개 테이블은 2TB이고 만드는 데 몇 달이 걸렸음: https://github.com/0xh4di/GSMDecryption?tab=readme-ov-file
    이제 더 이후 세대에도 이런저런 이유나 특정 국가 행위자 때문에 복호화 구멍이 조금 있는지 궁금해짐

  • 재미있는 작업이고, 이런 오픈소스가 아직 쓰이는 걸 보니 반가움
    10년쯤 전 대학 네트워크 보안 연구실에서 다운링크 도청을 해봤음
    프로젝트 중 하나는 봄방학 동안 셀 활동량이 얼마나 줄어드는지 측정하는 것이었고, 또 하나는 알려진 위치의 알려진 전화번호에 대해 타이밍 공격을 해서 임시 ID를 뽑아낼 수 있는지 확인하고, 반복 호출로 아직 그 지역에 있는지 보는 것이었음
    그 임시 ID는 개인적으로 충분히 임시적이지 않았다고 봄. 다시 만져보고 싶어짐

  • 정보를 추출하는 데 쓸 수 있는, 망가진 디버그 모드가 알려진 4G 동글들도 있음

  • LTESniffer는 오픈소스라고 하지만, 최상위 LICENSE 파일도 없고 GitHub 저장소 라이선스 설정도 없어 보임