gnosis@kim:~#

gnosis@kim:~ # cat blog/rolljam-3-extensions-and-wrap-up.md

# 3. RollJam extensions & wrap-up

[Analysis]series/RollJam28 min read[ko]

#Automotive#RF

인트로: 끝난 줄 알았지? (The Nightmare Continues)

2015년 Samy Kamkar의 RollJam이 공개됐을 때, 제조사들은 꽤 빨리 대응을 시작했습니다.

겉으로 보기에는 “이제 RollJam은 옛날 얘기 아닌가?” 싶습니다.

하지만, 방어가 한 발 나가면 공격은 두 발 나갑니다.

  • RollBack은 “이미 사용해서 무효가 된 과거 코드”를 다시 유효하게 만들고
  • SDR RollJam / FHSS RollJam / Enhanced RollJam은 하드웨어와 파형 레벨에서 RollJam을 “업그레이드”하고
  • RollCAN은 RF를 포기하고 아예 CAN 버스로 점프해 RollJam 철학을 이식합니다.
  • 마지막으로 AI/ML 기반 공격/방어가 등장하면서, RKE 보안은 완전히 다른 국면으로 들어가고 있습니다.

이번 편에서는 단순 나열이 아니라, “방어가 바뀔 때마다 공격이 어떻게 형태를 바꿔 따라붙었는지”를 축으로 RollJam 이후의 7가지 계보를 기술적으로 파헤쳐 봅니다.

3.1 RollBack: 시간을 되돌리는 공격

키워드: Time-agnostic Replay, Resynchronization Abuse

  • 발표: Black Hat USA 2022, 이후 저널 논문으로 확장 (L. Csikor et al.)
  • 요약: _“한 번만 쓰고 버린다”_는 롤링코드의 전제를 부정
  • 핵심: 재동기화(Resync) 로직의 버그를 이용해 과거의 코드를 부활

3.1.1 RollJam vs RollBack – 철학의 차이

구분RollJamRollBack
타깃RKE + RollJam 취약 차량 전반특정 제조사 RKE 구현 (Honda, Nissan, Kia, Hyundai 등)
필요 조건실시간 Jamming + CaptureJamming 불필요, 단순 캡처
캡처 시점공격 시점에 현장에서 수행과거에 한 번 캡처해두면 됨
재사용 가능성한 번 쓰면 끝 (그 코드 소멸)시간 무관(Time-agnostic)·반복 가능

RollJam은 미래에 쓸 수 있는 코드 하나를 ‘예약’하는 공격이었습니다, 반면 RollBack은 아예 “과거로 롤백해서, 이미 쓴 코드를 다시 유효하게” 만듭니다.

3.1.2 공격 원리: Resynchronization의 배신

RKE 시스템에는 “카운터가 너무 멀어졌을 때”를 복구하기 위한 Resync 메커니즘이 있습니다.

일반적인 그림은 이렇습니다.

  1. 차량은 마지막으로 본 카운터 Ctr_car를 기억하고 있음
  2. FOB에서 들어온 코드가
Ctr_car < Ctr_rx ≤ Ctr_car + W (윈도우 내) → 정상
Ctr_rx가 너무 커서 윈도우 밖 → 별도의 Resync 알고리즘 실행

문제는, 일부 구현에서 이 Resync 로직이 허술하거나, 아예 잘못 구현되어 있었다는 것입니다.

RollBack 논문의 핵심 포인트:

즉, 카운터 검증 로직이 꼬이면서:

지금부터는 과거에 썼던 시퀀스 전체를 다시 받아들이겠습니다.

라는, RKE 설계 철학과 정반대의 상태로 떨어지는 것.

3.1.3 공격 흐름 (간단 시나리오)

Fig. 2 출처: RollBack: A New Time-Agnostic Replay Attack Against the Automotive Remote Keyless Entry Systems

Fig. 2 출처: RollBack: A New Time-Agnostic Replay Attack Against the Automotive Remote Keyless Entry Systems

  1. Capture 단계
    • 공격자는 타깃 차량 근처에서 RKE 신호를 일정 시간 수집
    • 예: C100, C101, C102, C103, ... (카운터 100, 101, 102, 103...)
  2. 사용자 일상 사용
    • 피해자는 평소처럼 FOB를 쓰면서 카운터를 200, 300… 까지 올려버림
    • 이 시점에서 RollJam 방식 리플레이는 이미 끝장 (과거 코드 무효)
  3. Trigger 단계
  4. Rollback 단계
    • 내부 상태 머신/카운터 관리 버그 때문에 RKE 수신기가 이전 상태로 돌아간 것처럼 동작
    • 이후 이미 사용한 코드들(C100~C121…)도 다시 수용
  5. Exploit
    • 공격자는 과거에 캡처해 둔 코드들을 하나씩 재생해 언제든 차량을 열 수 있게 됨.

이 공격은 Jamming이 전혀 필요 없고, “언제, 어디서 캡처했는지”와 상관없이 나중에 반복적으로 쓸 수 있기 때문에, 연구진이 “Time-agnostic Replay Attack” 이라고 부른 이유가 됩니다.

3.1.4 실제 영향

방어 측면 메시지는 명확합니다.

“Resync는 UX를 위한 예외 처리라고 가볍게 구현했는데, 알고 보니 그 자체가 새로운 공격 표면이었다.”

3.2 RollBack 변형들: Sequence/Overflow 계열

RollBack은 하나의 PoC가 아니라, “Resync 로직을 틀리게 짠 모든 구현을 관통하는 공격 패턴”에 가깝습니다.

실제 분석·PoC들을 보면, 패턴은 대략 두 가지 계열로 정리할 수 있습니다.

3.2.1 Sequence-based RollBack

아이디어: “특정 시퀀스의 명령 조합이 내부 상태 머신을 엉망으로 만든다”

공격자는 이 “비정상 시퀀스”를 이용해

  1. RKE를 Resync 모드로 몰아넣고
  2. 과거 코드/미래 코드들을 다시 유효하게 만드는

RollBack-like 상태를 유도할 수 있습니다.

3.2.2 Overflow-based RollBack

아이디어: “카운터 오버플로우를 제대로 처리 안 하면, 다시 0으로 돌아가는 순간이 생긴다”

이 경우 공격자는:

  1. 의도적으로 카운터를 최댓값까지 밀어붙이고
  2. 오버플로우 이후 구간에서
  3. 과거 코드/특정 시퀀스를 재생해 재동기화/롤백을 유도할 수 있습니다.

요약: RollJam이 “윈도우 앞쪽(미래)”를 공략한다면, RollBack 계열은 “윈도우 뒤쪽(과거)과 롤오버 지점”을 공략하는 공격입니다.

3.3 SDR RollJam: 하드웨어의 족쇄를 끊다

키워드: Wideband, Multi-modulation, Toolchain

초기 RollJam은 CC1101 + Teensy라는 저가형 조합을 썼습니다.

그래서 자연스럽게 이어진 게 SDR(Software Defined Radio) 기반 RollJam입니다.

대표적인 SDR 중 하나인 HackRF One

대표적인 SDR 중 하나인 HackRF One

3.3.1 연구 사례: Unibo의 SDR RollJam 구현

2024년 Stabili et al. 은 “Implementing and testing RollJam on Software-Defined Radios”라는 논문에서, HackRF/USRP 계열 SDR로 RollJam 전체 체인을 구현·평가했습니다.

핵심 포인트:

3.3.2 RFQuack: RollJam을 모듈로 제공하는 툴킷

Maggi et al. 의 RFQuack 프로젝트는 멀티 라디오 하드웨어 + 펌웨어 + Python 툴로 구성된 “범용 무선 프로토콜 해킹 툴킷”입니다.

두 개의 RFQuack 모듈형 동글.

두 개의 RFQuack 모듈형 동글.

재미있는 점:

즉, RollJam은 더 이상 “한 해커의 PoC”가 아니라, 툴킷의 한 기능 수준으로 추상화되어 버렸다는 것입니다.

“무선 프로토콜 보안 분석”을 한다고 하면, RollJam 클래스 공격은 기본 레퍼토리로 들어간 시대.

3.4 FHSS RollJam: 주파수 호핑 위에서 춤추기

키워드: FHSS, Wideband / Reactive Jamming

RollJam이 공개된 이후, 업계가 가장 먼저 꺼내든 방어 카드 중 하나가 FHSS입니다. (구글 특허)

그러면 “RollJam은 FHSS 나오면 끝난 거냐?” → 당연히 공격자도 가만있지 않았습니다.

3.4.1 Wideband Jamming

SDR + 충분한 출력이 있다면, 애초에 “개별 채널”이라는 개념을 무시해 버릴 수 있습니다.

단점:

하지만 실험실/PoC/근거리 기준에서는 충분히 가능하고, 일부 논문/특허에서도 “FHSS라도 Wideband Jam에는 취약”하다는 점은 반복적으로 지적됩니다.

3.4.2 Reactive Jamming

조금 더 “똑똑한” 방식은 Reactive Jammer입니다.

  1. 공격자는 SDR로 RKE 대역을 수신 모드로 모니터링
  2. 특정 특징:
    • Preamble 패턴
    • FFT 상의 에너지 변화
    • 제조사별 시그니처등을 기반으로 “지금 FOB가 말하기 시작했다”를 감지
  3. 감지 순간:
    • 스크립트/FPGA 로직이 즉시 Jam 신호 발사
    • 호핑 시퀀스를 어느 정도 역공학했다면, “다음에 이동할 채널”에도 선제적으로 Jam 준비

이 방식은:

결국 FHSS 도입은 난이도·비용을 올렸지만, Wideband + Reactive Jamming + SDR 조합에는 취약할 수밖에 없다는 게 현재까지의 결론입니다.

3.5 Enhanced RollJam: “스텔스” 지향 지능형 Jamming

키워드: Smart Jamming, Low-duty Interference

초기 RollJam은 꽤 무식한 방식이었습니다.

최신 차량들은 “비정상적인 지속 Jam 패턴”을 RF 레벨에서 탐지하고 알람을 띄우거나, 아예 해당 상황에서 RKE를 비활성화하는 방어책을 일부 도입했습니다.

그래서 등장하는 개념이 Enhanced/Stealth RollJam입니다.

3.5.1 Smart Jamming 전략

기본 아이디어:

“필요한 순간에만, 아주 짧게, 최소한만 때리자”

구체적으로는:

  1. Preamble 스니핑
    • CC1101/SDR에서 Preamble+Sync Word 감지용 로직만 항상 돌려둠
    • “이건 FOB 패킷 같다” 판단되면
  2. 핀포인트 Jam
    • Preamble 끝나고, Payload 구간 일부에만
    • 수 ms~수십 ms 단위로 Jam
    • 차량 입장에서는:
      • Sync는 찾았는데
      • CRC가 안 맞거나
      • 데이터 일부가 깨져서 그냥 버리는 상황
  3. 저 duty-cycle
    • 전체 시간 대비 Jam ON 시간 비율을 극단적으로 낮춰:
      • RF 모니터링 장비·탐지 로직이
      • “특정 패턴의 Jam”을 통계적으로 인지하기 어렵게 함

RFQuack 같은 툴킷은 이미 “패킷이 특정 패턴과 매칭되면, 그때만 개입”하는 in-flight packet filtering / manipulation 기능을 지원합니다.

이 개념을 RollJam에 적용하면:

라는, 공격자 입장에서는 “맛있는 조합”이 됩니다.

Stabili 등의 SDR RollJam 구현에서도 Jamming 타이밍/지속시간 최적화가 성공률·은닉성의 핵심 변수로 등장합니다.

3.6 RollCAN / CAN RollJam: RF가 막히면 선을 탄다

키워드: In-vehicle Network, CAN Error-based Jamming

이제부터는 더 노골적인 이야기입니다.

“무선이 까다로워지면, 그냥 차 안으로 들어가서 CAN 버스를 건드리면 되지 않나?”

2025년 Hamborg et al. 은 “RollCAN – CAN-bus based RollJam-Attack”를 발표합니다.

아이디어 한 줄 요약:

“RollJam의 Jam & Capture 패턴을 RF 대신 CAN 버스에 적용해 보자.”

3.6.1 공격 벡터

3.6.2 Jam & Capture in CAN

RollCan 시스템 아키텍처 출처: RollCAN – CAN-bus based RollJam-Attack

RollCan 시스템 아키텍처 출처: RollCAN – CAN-bus based RollJam-Attack

CAN 버스에서 “Jamming”은 RF와는 방식이 다릅니다.

  1. Sniff
    • 공격 장비가 CAN 버스를 모니터링
    • 사용자의 RKE 조작으로 인해 “문 열어” CAN 프레임이 지나가는 시점 포착
  2. Inject (Jamming)
    • 같은 순간에 더 높은 우선순위 ID를 보내거나
    • 에러 프레임을 연속적으로 쏴서
    • 원래의 도어락 메시지가 버스 상에서 충돌/취소되도록 유도
  3. Capture
    • 원래 도어락 메시지는 일부 ECU에 전달되지 못했지만
    • 공격 장비는 이미 그 내용(롤링코드/상태)을 캡처해 둔 상태
  4. Replay
    • 나중에 공격자가 같은 CAN 프레임을 단독으로 쏘면, 도어 ECU는 이를 정상 메시지로 받아들이고 문을 열어 줌.

즉, 논문이 말하듯:

“RollCAN은 물리적으로 RF를 공격하지 않고, RKE 메시지가 흘러가는 차량 내부 네트워크를 공격한다.”

3.6.3 의미

그래서 최근 SoK·스마트키 보안 동향 논문들은

3.7 AI RollJam: 스스로 학습하는 공격·방어 도구

키워드: RF Classification, Pattern Learning, Protocol Fuzzing

마지막은 현재진행형·미래형에 가까운 이야기입니다.

“AI RollJam”이란 이름의 정식 논문이 있는 건 아니지만, 이미 퍼즐 조각은 다 나와 있습니다.

3.7.1 RF 신호 분류(Classification) – 공격·방어 양면 칼

최근 무선 통신 분야에서는:

같은 주제에 CNN/LSTM/Attention 같은 딥러닝이 활발히 적용되고 있습니다. RKE 특화 연구도 이미 등장했습니다.

이는 방어 입장에서 큰 희망입니다.

를 RF 레벨에서 AI가 분류할 수 있기 때문입니다.

하지만 공격자 입장에서도 이런 기술은 그대로 무기화될 수 있습니다.

3.7.2 공격 관점에서의 AI 활용 시나리오

예를 들어, “AI RollJam”을 상상해 보면:

  1. Signal Classification
    • SDR로 들어오는 수많은 신호 중에서 “이건 특정 제조사 FOB 신호다”를 딥러닝 기반 분류기로 실시간 식별
    • 여러 제조사/프로토콜이 섞인 주차장 환경에서 타깃 차량 신호만 골라 공격 가능
  2. Jamming 타이밍 최적화
    • 다양한 Jam 타이밍/지속시간/파형을 탐색하면서,
    • “어떤 패턴에서 차량이 가장 잘 열리고, 로그도 안 남는지”를 RL(강화학습)·AutoML로 자동 탐색
  3. Resync/윈도우 Reverse Engineering
    • 차량별로 롤링코드 허용 윈도우·Resync 패턴을 ML이 관측·학습해
    • RollBack/Enhanced RollJam 성공 확률이 높은 “최적 시퀀스”를 스스로 찾아낼 수 있음

즉, 지금까지 사람 손으로 하던 “Protocol Reconnaissance”을 AI가 대신 수행하는 시대가 오는 건 시간문제입니다.

[결론] RollJam 유니버스에서 살아남는 법

RollJam → RollBack → SDR/FHSS/Enhanced RollJam → RollCAN → AI RollJam까지 짧게는 10년 남짓한 시간 동안, 공격과 방어는 이렇게 오고 갔습니다.

패턴을 요약하면:

  1. 암호가 아니라 프로토콜이 털린다
    • KeeLoq, AES 자체를 깨서 들어간 게 아니라
    • 롤링코드 윈도우, Resync, PKE/RKE UX가 뚫림
  2. 방어가 한 층 생기면, 공격은 한 단계 더 아래로 내려간다
    • RF 레벨 방어 → 프로토콜 레벨 공격 (RollBack)
    • 프로토콜 패치 → PHY/SDR/FHSS 공격
    • RF 하드닝 → CAN 내부 RollCAN
    • 룰 기반 탐지 → AI 기반 분류/탐지/공격
  3. “완벽한 방어”는 없지만, “비용을 기하급수적으로 올리는 방어”는 가능하다
    • Timestamp + 양방향 인증 + Secure CAN + UWB 등 여러 층을 쌓으면, 공격 난이도/비용/리스크는 급격히 증가합니다.

보안 담당자/연구자 입장에서의 take-away:

✅ 마무리: SoK의 4가지 질문으로 다시 정리하는 “RollJam 유니버스”

여기까지 우리는 RollJam 이후 공격이 어떻게 “진화”했는지(롤백, SDR, FHSS 대응, CAN으로의 점프, AI까지) 계보를 따라왔습니다.

그런데 이 흐름을 한 번 더 깔끔하게 정리해 주는 프레임이 있습니다. SoK 논문은 결론을 4개의 Research Question(RQ)에 대한 답으로 닫습니다.

RQ1) 기술 진화가 보안을 높였는가?

부분적으로는 그렇다.

암호 자체를 깨는 공격(cryptographic attacks)은 점점 어려워졌습니다. 하지만 그 대신 공격은 “암호”보다 더 아래/바깥을 파고듭니다. 즉 릴레이 같은 물리 계층 공격, 그리고 웹/백엔드 기반 공격 표면이 새로 강해졌습니다.

→ 이 글의 관점에서 말하면: “RollJam을 막는 패치”가 생겨도, 공격은 RollBack·Relay·Web·In-vehicle로 형태를 바꾸며 살아남았습니다.

RQ2) 공격 전략은 변했는가?

크게 변하지 않았다.

SoK가 강조하는 요지는, “새로운 변종이 쏟아져도 핵심 클래스(relay/replay)는 계속 남는다”는 점입니다. 특히 릴레이 공격은 여전히 강력하고 접근 난이도가 낮은 편이라, 현실에서 가장 무서운 카드로 남아 있습니다.

→ 그래서 “RollJam 유니버스”를 다룰 때도, 신기한 변종보다 지속적으로 살아남는 공격 클래스를 기준으로 모델링하는 게 실무적으로 더 중요합니다.

RQ3) 방어책은 효과적이고 배포 가능한가?

논문 속 방어책은 ‘좋은 아이디어’인 경우가 많지만, 상용 적용은 드물다.

비용(하드웨어 추가), 복잡도(프로토콜 변경), 레거시 호환성(기존 차량/키) 때문에, 학계에서 제안된 많은 방어책이 실제 차량에 널리 들어가진 못했다는 결론입니다.

→ “가능한 방어”와 “배포 가능한 방어”는 다릅니다. 그래서 설계/보안 검토에서 현실 제약(원가, 생산, 유지보수, 규제, 사용자 UX)을 같이 넣어야 합니다.

RQ4) 그럼 무엇이 필요하나?

SoK의 결론은 꽤 직설적입니다. security-by-obscurity(폐쇄적 보안)에 기대는 방식에서 벗어나, 투명성과 커뮤니티 협력이 필요하다고 말합니다. 또한 앞으로의 큰 축으로 웹 API/웹 서비스 보안과 UWB 구현의 표준화된 가이드라인(“UWB를 쓴다”가 아니라 “안전하게 구현한다”)을 강조합니다.

→ 즉, 앞으로의 RKE/PKES 보안은 “RF만 잘하면 끝”이 아니라 RF + 차량 내부 네트워크 + 클라우드/앱 생태계까지 한 덩어리로 봐야 한다는 이야기입니다.

AutoHack2025를 준비하며 알게 된 RollJam으로 이렇게 3부작 글을 마무리하게 되었네요. 보안은 역시 너무나도 넓습니다.

질문, 오류가 있다면 댓글로 남겨주세요. 감사합니다!

참고자료

[Main SoK Paper]

[Evolution 1: RollBack & RollingPwn]

[Evolution 2: SDR & Enhanced Jamming]

[Evolution 3: Network & AI]

#open original ↗#cd ../