Edge Device와 Fault Injection - 세미나 발표

 

 

 

 

Mixture Of Experts 구조와 Mixed Precision Offloading 기술의 발전으로 컴퓨팅 리소스가 부족한 엣지 디바이스에서도 LLM을 실행할 수 있게 됐습니다.

 

HOBBIT 등 관련 연구가 계속되면서, VRAM이 8GB 정도인 환경에서 GPT-4o급 성능을 보이는 Mixtral 8x7B 모델을 실행시키는게 가능할 정도로 성능이 크게 향상되었습니다.

 

다만, 성능이 좋아질수록 복잡한 캐시 계층 구조 및 아키텍처를 사용하게 되어 시스템 복잡도가 증가합니다. 

 

 

 

 

시스템이 복잡해질수록 외부 환경 및 의도적인 공격에 의한 물리적 오류에 노출될 가능성도 높아집니다.

단순히 오류를 발생시키는 것 뿐만 아니라, 애플리케이션 실행에 Fault를 발생시킬 수 있습니다.

 

열심히 모델 깎고 새로운 아키텍처를 도입해서 Edge Device에서 LLM을 실행시키더라도, Fault Injection 한 방으로 무너뜨릴 수 있습니다.

 

HOBBIT으로 잘 돌아가고 있는 모델의 특정 레지스터나 RAM에 Bit-Flip을 유도한다고 합시다.

모델의 가중치가 오염되어 완전히 잘못된 답변을 내놓거나, 비밀번호 확인 로직이나 권한 확인을 건너뛰어 보안 체계를 무너뜨릴 수 있습니다.

 

LLM 모델의 특성상, 특정 파라미터 또는 Key-Value 캐시에서 1비트만 뒤집어도 Hallucination을 유도할 수 있습니다.

Regressive 특성 때문에 초기 토큰의 미세한 오류가 다음 토큰 생성에 누적되고 전체 답변의 신뢰도를 무너뜨릴 수도 있구요.

 

 

 

 

 

Fault Injection 관련 논문입니다. SoK 논문이 있어 관련 지식을 쉽게 찾아볼 수 있었습니다.

정리한 글은 여기에서 확인할 수 있습니다.

 

근본 원인은 신호가 0인지 1인지 모호한 상태인 Metastability를 가질 수 있다는 것이고, 공격의 목표는 Single Event Upset을 통해 Bit-Flip을 발생시키는 것 입니다. 

 

공격의 목표는 하나지만 그 목표를 수행하는 방법은 여러 가지입니다. 논문에서는 총 5가지 방식을 다뤘습니다.

여기서 주목할 부분은 공격의 목표가 하나라는 부분입니다.

 

어떤 방식으로 Fault Injection을 수행하든간에, CPU 내부에서는 이벤트가 발생합니다. 

 

Performance Monitoring Unit은 실행 중 발생하는 Clock Cycle, Cache Miss, Branch 통계 등을 추적합니다.

Hardware Performance Counters는 저런 이벤트를 기록합니다.

 

결함이 발생해 Bit-Flip이 발생한다면 저 HPC 지표들이 평소와는 다른 패턴을 보이게 되고, 저런 CPU의 미세한 지표 변화를 학습해 공격을 실시간으로 탐지하겠다는 전략을 세울 수 있습니다.

 

 

 

 

목표가 Bit-Flip 하나니까 단순히 비트가 뒤집혔다는 결과만 학습해야겠다고 생각할 수 있는데, 다섯 가지 공격 방식 모두 고려해야 합니다.

 

비트가 뒤집힌다는 현상에 도달하기까지 CPU와 메모리가 보여주는 전조 현상은 공격 기법마다 다릅니다.

 

RowHammer는 특정 메모리 행을 반복해서 읽어야 하니 Cache Miss와 Memory Access Count 지표가 폭발적으로 상승하고, Glitch 류 공격은 CPU 파이프라인에서 Branch Misprediction이 빈번하게 발생합니다.

 

또 EMFI 공격은 전자기 충격이 가해지는 순간 유도 전압으로 여러 하드웨어 카운터가 동시에 튀는 현상이 관찰됩니다.

FI Laser 공격도 결함이 전파되는 과정에서 흔적을 남길 수 밖에 없으니, 해당 HPC 신호를 통해 감지할 수 있습니다. 

 

 

 

 

M5Stack Core2로 물리적 충격이나 전자기적 노이즈를 감시합니다. (EMFI 탐지)

라즈베리파이 내부의 PMU는 cycles, instructions, cache-misses, branch-miss 등 실시간으로 HPC 데이터를 수집합니다.

 

M5Stack Core2와 PMU로 수집한 데이터는 학습된 TinyML로 전달됩니다. 

 

우선, 지금 공격당하고 있는지를 실시간으로 판별하는 Binary Classifier 역할을 수행합니다.

라즈베리파이 모델을 정상적으로 사용할 때의 패턴을 학습하고, HPC Pulse가 정해놓은 Threshold를 벗어나면 Anomaly Detected 신호를 발생시킵니다. 

 

간단한 작업을 수행하니 Pi Zero에서 충분히 구동할 수 있습니다.

공격 패턴이 확실하다면 즉시 Output을 만들고, 판단이 애매한 경우 외부 LLM으로 정밀 분석을 요청합니다.

 

이제 이 공격이 어떤 종류의 공격이고, 어떻게 대응해야 하는지를 분석할 때는 외부 LLM 서버를 사용합니다.

Anomaly Detected 포착 전후 k ms 정도의 HPC 로그 스냅샷과 관련 로그를 외부 LLM 서버로 전송합니다. 

 

수집된 데이터를 분석해 공격 유형을 진단하고, 진단 결과에 따른 대응 방안을 Edge Device로 보냅니다. 

 

Output은 정의하기 나름인데, LLM의 경우 리포트 작성 및 하드웨어 제어 커맨드가 될 수 있겠고, TinyML은 현재 공격받는 여부 및 확률과 특정  프로세스 중지 정도가 될 수 있겠습니다. 

 

HPC 지표를 차트로 시각화 하는것도 좋아보입니다.

 

 

 

 

 

이제 TinyML을 어떻게 학습시키는지에 대해서 살펴보겠습니다.

우선 참고한 논문이 하나 있습니다. 실제로 Bit-Flip 발생 시 어떤 신호가 감지되는지 확인하는 논문입니다.

자세한 내용은 여기에서 확인할 수 있습니다.

 

일단 이 논문에서는 Bit-Flip을 유발하는 다섯 가지 방식을 각각 다루지는 않고, 그 결과인 Bit-Flip 자체에 집중합니다.

Bit-Flip 성공 시, 시스템의 동작은 세 가지로 분류됩니다.

 

Bit-Flip이 발생했지만 결과가 바뀌지 않는 경우와, Bit-Flip이 발생했고 결과도 바뀌는 경우, Bit-Flip이 발생해 시스템이 망가지는 경우입니다.

 

 

 

 

우측 이미지는 Bit-Flip으로 Benign과 SDC가 발생했을 때의 PCA 결과입니다.

SDC가 발생한 경우 정상 HPC 패턴과 대놓고 다르니 인공지능이 쉽게 학습할 수 있습니다.

Benign도 Cycles이나 내부 연산 흐름에 미세한 변화가 발생하니 이 타이밍의 불일치를 포착해 학습할 수 있을거라 생각합니다.

 

 

 

Glitch, EMFI 등 물리적 공격은 재현하기 힘들죠.

또, 특정 시점이나 위치를 정밀하게 타격하기도 힘들어 AI 학습에 필요한 일관된 데이터를 얻기가 어렵습니다.

 

그러니 소프트웨어로 제어하는 환경을 사용합니다.

단순한 시뮬레이션이 아니라, 실제 하드웨어 내부에 있는 JTAG을 소프트웨어로 조종하는 방식을 사용합니다.

 

어셈블리 명령어 단위로 원하는 비트만 정확하게 뒤집을 수 있어 데이터에 노이즈가 끼지 않습니다.

 

보통 CPU가 추적할 수 있는 이벤트에 비해 HPC의 개수가 너무 적어 데이터 수집이 어렵지만, 소프트웨어로 제어하는 방법을 사용하면 동일한 결함을 계속해서 주입할 수 있어 매번 다른 HPC 지표를 수집할 수 있으니 전체적인 결함 Pulse 패턴을 완성할 수 있습니다.

 

논문에 사용된 소스코드는 오픈소스로 공개되어있으니, 데이터 수집에 사용할 수 있습니다.

 

 

 

 

제가 제안하는 최종 아키텍처입니다.

 

M5Stack Core2로 Glitch나 EMFI 같은 물리적 공격의 원인이 되는 외부 환경 변화를 1차적으로 감시합니다.

외부 센서를 통과한 공격이라도 CPU 내부의 PMU가 HPC를 통해 Bit-Flip으로 인한 아키텍처의 반응을 포착합니다.

 

TinyML은 라즈베리파이 내부에서 실시간으로 HPC 데이터를 분석합니다. 

앞서 말씀드렸듯, SDC와 Benign 데이터는 정상 패턴과 뚜렷한 차이를 보이기에 TinyML이 이를 감지할 수 있습니다.

 

탐지된 이상치 로그를 전송받아 이게 어떤 종류의 공격인지를 상세하게 분석합니다.

단순한 탐지를 넘어 사고 리포트 작성 및 향후 방어 전략 수집으로 이어질 수 있습니다.

 

Cloud LLM의 성능을 위해 필요하다면 RAG를 적용하는것도 좋아보입니다.