25. Security & Privacy 단계별 학습 문서

원문 경로

/Users/keumky/Documents/New project 3/sources/mlsysbook/25-privacy_security/source.md

짧은 소개

이 장은 머신러닝 시스템에서 보안과 프라이버시가 왜 핵심 설계 조건인지 설명해요. 머신러닝 시스템은 단순히 데이터를 잠깐 처리하고 끝내는 프로그램이 아니라, 데이터에서 배운 패턴을 모델 파라미터 안에 오래 보관해요. 그래서 모델이 잘못 학습되거나, 훔쳐지거나, 입력에 속거나, 하드웨어 수준에서 공격받으면 개인정보와 조직의 자산, 실제 물리 시스템의 안전까지 영향을 받을 수 있어요.

원문은 먼저 보안과 프라이버시의 차이를 분명히 나눈 뒤, Stuxnet, Jeep Cherokee 해킹, Mirai 봇넷 같은 실제 보안 사고에서 배울 점을 살펴봐요. 이어서 모델 탈취, 데이터 포이즈닝, 적대적 공격, 하드웨어 취약점, 공격 도구로 쓰이는 머신러닝, 계층적 방어, 구현 로드맵, 흔한 오해를 차례로 다룹니다.

읽는 방법

처음부터 모든 세부 공격 기법을 외우려 하지 않아도 괜찮아요. 이 장은 다음 순서로 반복해서 읽으면 훨씬 잘 이해돼요.

1. 먼저 목차와 요약을 보며 “ML 시스템은 데이터, 모델, API, 하드웨어 전체가 공격 표면이구나”라는 큰 그림을 잡아요.
2. 그다음 역사적 사고 사례를 읽으며 공급망, 격리 실패, 약한 엔드포인트라는 세 가지 패턴을 기억해요.
3. 이후 모델 탈취, 데이터 포이즈닝, 적대적 공격을 ML 생명주기 위에 올려 놓고 어느 단계에서 발생하는지 확인해요.
4. 마지막으로 방어 기법을 데이터 계층, 모델 계층, 런타임 계층, 하드웨어 계층으로 나누어 다시 정리해요.

데이터 수집 -> 학습 -> 모델 배포 -> 추론 실행 -> 모니터링/대응
    |          |          |            |              |
 포이즈닝    백도어     모델 탈취    적대적 입력    탐지/롤백

이 장의 한 줄 요약

머신러닝 보안과 프라이버시는 모델 파일 하나를 숨기는 문제가 아니라, 데이터가 들어오는 순간부터 모델이 실행되는 하드웨어와 사고 대응까지 전 계층에서 위험을 줄이는 시스템 설계 문제예요.

1단계: 중학교 수준

1. 보안과 프라이버시는 비슷하지만 달라요

보안은 집의 문과 자물쇠에 가까워요. 누군가 허락 없이 들어와서 물건을 훔치거나 망가뜨리지 못하게 막는 일이에요.

프라이버시는 집 안에 있는 내 일기장과 가족사진을 아무나 보지 못하게 하는 일에 가까워요. 도둑이 들지 않았더라도, 내 민감한 정보가 원하지 않는 방식으로 드러나면 프라이버시 문제가 생겨요.

머신러닝에서는 이 차이가 중요해요. 모델이 해킹당해서 조작되면 보안 문제이고, 모델이 학습 중 본 개인정보를 나중에 말해 버리면 프라이버시 문제예요.

2. ML 시스템은 “배워서 기억하는” 시스템이에요

일반 프로그램은 보통 입력을 받고 정해진 규칙대로 결과를 내요. 계산기처럼 2를 넣고 3을 더하면 5가 나오는 식이에요.

하지만 머신러닝 모델은 데이터를 많이 보고 “패턴”을 배워요. 마치 학생이 문제집을 풀면서 자주 나오는 유형을 기억하는 것과 비슷해요. 문제는 이 기억 속에 민감한 내용이 섞일 수 있다는 점이에요.

예를 들어 병원 대화 기록으로 학습한 챗봇이 특정 환자의 말을 그대로 떠올려 답한다면, 시스템이 정상적으로 작동했더라도 프라이버시 실패예요.

3. 역사적 보안 사고에서 세 가지 교훈을 배워요

원문은 ML만의 사례가 아닌 일반 보안 사고도 중요하게 다뤄요. 이유는 공격 패턴이 ML 시스템에서도 반복되기 때문이에요.

4. 모델도 훔쳐지고, 속고, 오염될 수 있어요

모델 탈취는 누군가 비싼 시간과 돈을 들여 만든 모델을 몰래 가져가거나 흉내 내는 일이에요. 레시피를 훔쳐 같은 맛을 내는 가짜 가게를 여는 것과 비슷해요.

데이터 포이즈닝은 학습 재료에 나쁜 재료를 몰래 섞는 일이에요. 강아지에게 “앉아”를 가르치는데 누군가 일부러 잘못된 보상을 계속 주면 강아지가 엉뚱하게 배우는 것과 비슷해요.

적대적 공격은 겉보기에는 거의 똑같은 입력을 살짝 바꿔 모델을 속이는 일이에요. 사람 눈에는 정지 표지판으로 보이는데, 모델은 속도 제한 표지판으로 착각하게 만드는 식이에요.

5. 하드웨어도 안전해야 해요

모델은 결국 컴퓨터 칩, 메모리, 센서, 네트워크 장치 위에서 돌아가요. 그래서 소프트웨어만 튼튼해도 충분하지 않아요.

스마트 도어락이 아무리 좋은 얼굴 인식 모델을 써도, 누군가 센서를 바꿔치기하거나 기기 내부의 비밀 키를 빼내면 위험해요. 하드웨어 보안은 이런 물리적 기반을 지키는 일이에요.

6. 한 겹 방어로는 부족해요

중요한 건 “완벽한 방어 하나”를 찾는 게 아니에요. 집을 지킬 때도 문 잠금, 창문 잠금, 경보, CCTV, 이웃 신고가 함께 작동하듯이 ML 시스템도 여러 겹의 방어가 필요해요.

데이터 보호
  -> 모델 보호
    -> API와 실행 중 감시
      -> 하드웨어 신뢰 기반
        -> 사고 대응과 복구

1단계 중간 정리

이 장의 핵심은 “AI도 시스템이다”라는 사실이에요. 시스템이기 때문에 공격받을 수 있고, 데이터를 배우기 때문에 개인정보를 새게 할 수 있고, 실제 세상과 연결되기 때문에 안전 문제로 커질 수 있어요.

2단계: 고등학교 수준

1. 보안과 프라이버시를 논리적으로 구분해볼게요

보안은 주로 공격자의 행동을 막는 문제예요. 누가 모델을 조작하려 하는지, 데이터를 훔치려 하는지, 서비스를 멈추게 하려 하는지 살펴봐요.

프라이버시는 정보 노출을 제한하는 문제예요. 공격자가 없더라도 모델이 학습 데이터를 지나치게 기억하거나, 출력에서 개인 정보를 추론할 수 있으면 프라이버시 위험이 있어요.

둘은 서로 도와주기도 하고 충돌하기도 해요. 암호화는 보안과 프라이버시에 모두 도움이 되지만, 너무 많은 로그를 남기는 보안 모니터링은 프라이버시 위험을 키울 수 있어요. 반대로 차등 프라이버시는 개인정보 노출을 줄이지만 모델 정확도를 낮출 수 있어요.

2. ML 생명주기별 공격 표면

원문은 공격을 ML 생명주기 위에서 이해하라고 말해요. 공격은 아무 때나 똑같이 일어나지 않아요. 단계마다 노리는 대상이 달라요.

3. 위험 우선순위는 가능성과 피해로 정해요

모든 위험을 한 번에 막을 수는 없어요. 그래서 원문은 발생 가능성(likelihood)과 피해 규모(impact)를 함께 보라고 해요.

4. 모델 탈취를 간단한 함수 흉내내기로 볼 수 있어요

고등학교 수준에서는 모델을 하나의 함수처럼 생각해볼 수 있어요.

입력 x -> 모델 f -> 출력 y

공격자가 모델 내부를 직접 훔치면 정확한 탈취예요. 예를 들어 모델 파일, 가중치, 구조, 하이퍼파라미터를 가져가는 식이에요.

공격자가 내부를 보지 못해도, 입력을 많이 넣고 출력을 기록하면 비슷한 모델을 만들 수 있어요.

질문 x1, x2, x3, ...
  -> 원래 모델의 답 y1, y2, y3, ...
  -> 공격자가 새 모델을 훈련
  -> 비슷하게 대답하는 복제 모델 생성

이것이 근사 모델 탈취예요. 정확한 설계도를 훔치지는 않았지만, 겉으로 거의 같은 행동을 하는 복제품을 만드는 방식이에요.

5. 데이터 포이즈닝은 학습 목표를 거꾸로 이용해요

모델 학습은 대략 “오차를 줄이는 방향으로 규칙을 고치는 과정”이에요. 공격자는 여기에 악성 데이터를 섞어 모델이 잘못된 방향으로 오차를 줄이게 만들어요.

간단히 말하면 정상 학습은 다음을 목표로 해요.

정상 데이터로 학습 -> 테스트에서 오차를 줄이기

포이즈닝 공격자는 반대로 이런 목표를 가져요.

악성 데이터 조금 섞기 -> 특정 상황에서 오차를 키우기

예를 들어 정지 표지판 이미지를 일부러 속도 제한 표지판으로 라벨링해서 학습 데이터에 넣으면, 모델의 경계가 조금씩 흔들릴 수 있어요. 전체 정확도는 멀쩡해 보여도 특정 표지판에서 위험한 오답이 반복될 수 있어요.

6. 적대적 공격은 결정 경계를 건드려요

분류 모델은 입력 공간을 여러 구역으로 나눠요. 한쪽은 “정지 표지판”, 다른 쪽은 “속도 제한 표지판”처럼요.

적대적 공격은 입력을 아주 조금 움직여서 결정 경계 반대편으로 넘어가게 만드는 공격이에요.

사람 눈: 거의 같은 이미지
모델 입장: 결정 경계 반대편으로 이동한 이미지
결과: 높은 확신으로 틀린 답

이 공격은 학습 데이터를 바꾸지 않아도 돼요. 배포된 모델에 들어가는 입력만 조작해도 일어날 수 있어요.

7. 프라이버시 보호 기법의 기본 논리

프라이버시 보호 기법들은 “원본 정보를 덜 노출하면서 학습에 필요한 패턴은 유지하자”는 목표를 가져요.

8. 하드웨어 보안도 흐름으로 이해할 수 있어요

하드웨어 공격은 소프트웨어 규칙을 우회할 수 있어요. 그래서 “프로그램이 안전하다”와 “기기가 안전하다”는 같은 말이 아니에요.

칩 설계 결함 -> 메모리 격리 우회
물리적 접근 -> 센서/메모리/버스 조작
전력/시간 신호 관찰 -> 내부 정보 추론
공급망 오염 -> 처음부터 신뢰할 수 없는 부품 사용

이에 대응하려면 Secure Boot, TEE, HSM, PUF 같은 하드웨어 신뢰 기반이 필요해요. 각각은 부팅 시점, 실행 시점, 키 관리, 장치 고유 신원 확인을 맡는다고 보면 돼요.

2단계 중간 정리

이 장의 논리는 다음 한 줄 흐름으로 정리할 수 있어요.

ML은 데이터를 학습해 지속적인 모델을 만들기 때문에
데이터 조작, 모델 탈취, 입력 조작, 하드웨어 누출이 모두 위험하고,
방어도 데이터-모델-런타임-하드웨어 전체에 걸쳐 설계해야 해요.

3단계: 대학교 수준

1. Security and Privacy in ML Systems

원문은 먼저 현대 ML 시스템의 구조 변화에서 출발해요. 예전에는 데이터와 모델이 중앙 서버에 모여 있는 경우가 많았지만, 현대 ML은 클라우드, 엣지 장치, 온디바이스 학습, 연합 네트워크, 하이브리드 배포 환경으로 넓어졌어요. 이 구조 변화는 더 유연한 지능을 가능하게 하지만 공격 표면도 크게 넓혀요.

일반 소프트웨어와 ML 시스템의 핵심 차이는 “지속적인 학습 표현”이에요. 일반 소프트웨어는 입력을 잠깐 처리하고 정해진 규칙대로 출력하는 경향이 강해요. 반면 ML 시스템은 훈련 데이터의 통계적 패턴을 파라미터에 인코딩해요. 이 파라미터가 모델의 지식이 되기 때문에, 민감한 데이터가 모델 출력이나 반복 쿼리를 통해 드러날 수 있어요.

또한 ML 시스템은 데이터 수집 파이프라인, 분산 학습 인프라, 모델 서빙 시스템, 모니터링 시스템으로 이루어진 복합 구조예요. 어느 한 계층만 안전해도 충분하지 않아요. 데이터셋이 오염될 수 있고, 모델 저장소가 변조될 수 있고, API가 모델 추출 통로가 될 수 있고, 하드웨어가 사이드 채널을 만들 수 있어요.

따라서 이 장의 기본 관점은 보안과 프라이버시를 ML 생명주기 전체에 통합하는 것이에요. 원문은 보안과 프라이버시의 정의, 실제 사고에서 배울 패턴, ML 고유 취약점, 계층적 방어 아키텍처를 차례로 연결해요.

2. Foundational Concepts and Definitions

2.1 Security Defined

ML 보안은 적대적 행동으로부터 시스템을 지키는 일이에요. 여기에는 모델 파라미터, 학습 파이프라인, 배포 인프라, 데이터 접근 경로가 모두 포함돼요.

예를 들어 대중교통의 얼굴 인식 시스템이 특정 패턴의 입력 때문에 사람을 잘못 식별하거나 아예 실패한다면, 이는 런타임 보안 취약점이에요. 단순 정확도 문제가 아니라 시스템의 무결성과 가용성이 공격받은 상황이에요.

2.2 Privacy Defined

프라이버시는 민감한 정보의 노출과 오용을 제한하는 일이에요. 중요한 점은 프라이버시 실패가 꼭 명시적 공격 때문에만 생기는 것은 아니라는 점이에요.

의료 상담 기록으로 학습한 언어 모델이 환자 대화를 외워두었다가 공개 챗봇에서 재현한다면, 공격자가 시스템을 해킹하지 않았더라도 프라이버시 실패예요. 시스템이 정상적으로 작동하면서도 민감 정보를 과도하게 노출했기 때문이에요.

2.3 Security versus Privacy

보안과 프라이버시는 목표, 위협 모델, 완화 전략이 달라요.

2.4 Security-Privacy Interactions and Trade-offs

둘은 서로 보완해요. 접근 제어와 암호화는 무단 접근을 막아 프라이버시 보호에도 도움이 돼요. 민감 데이터를 덜 보관하는 설계는 침해 사고가 났을 때 노출 범위를 줄여 보안에도 도움이 돼요.

하지만 긴장 관계도 있어요. 차등 프라이버시는 모델이 특정 개인을 기억할 위험을 줄이지만, 잡음을 추가하기 때문에 정확도나 유용성이 떨어질 수 있어요. 암호화는 보안을 높이지만 감사와 투명성을 어렵게 만들 수 있어요. 의료, 금융, 공공안전처럼 민감한 영역에서는 이 균형을 정량적으로 검토해야 해요.

3. Learning from Security Breaches

원문은 세 가지 역사적 사건을 통해 ML 보안 사고를 읽는 패턴을 제시해요. 이 사건들이 모두 ML 사건은 아니지만, 공급망 오염, 격리 실패, 엔드포인트 무기화라는 보편 패턴이 현대 ML 배포에도 그대로 적용돼요.

3.1 Supply Chain Compromise: Stuxnet

Stuxnet은 2010년에 발견된 정교한 웜으로, 이란 Natanz 핵시설의 산업 제어 시스템을 표적으로 삼았어요. 여러 제로데이 취약점을 이용해 Windows와 Siemens Step7 환경을 공격했고, 공기 격리된 시설에도 감염된 USB 같은 물리 매체를 통해 침투한 것으로 설명돼요.

핵심은 디지털 공격이 물리 장비의 손상으로 이어졌다는 점이에요. Stuxnet은 원심분리기를 제어하는 PLC를 조작해 실제 산업 장비를 방해했어요.

ML 시스템에서 이에 대응되는 위험은 공급망 공격이에요.

방어는 모델 아티팩트, 데이터셋, 의존성에 대한 암호학적 서명 검증, 출처 추적, 배포 전 무결성 검사, 민감한 학습 환경의 격리로 이어져요.

3.2 Insufficient Isolation: Jeep Cherokee Hack

2015년 Jeep Cherokee 해킹은 연결된 제품에서 격리가 얼마나 중요한지 보여줬어요. 연구자들은 차량의 Uconnect 엔터테인먼트 시스템 취약점을 통해 원격으로 접근했고, 엔진, 변속기, 제동 같은 안전 중요 기능에 영향을 줄 수 있음을 보였어요.

ML 시스템에서도 비슷한 위험이 있어요. 외부에 노출된 음성 인식 API, 네비게이션 모델, 스마트홈 제어 모델, 산업 IoT 추론 엔드포인트가 안전 중요 제어 시스템과 제대로 분리되지 않으면, API 취약점이 물리적 위험으로 이어질 수 있어요.

방어의 핵심은 격리예요.

3.3 Weaponized Endpoints: Mirai Botnet

Mirai 봇넷은 기본 비밀번호를 쓰는 카메라, DVR, IoT 장치를 대량 감염시켜 대규모 DDoS 공격에 사용한 사건이에요. 원문은 이를 ML 엣지 장치의 미래 위험과 연결해요.

전통 IoT 장치는 주로 트래픽을 발생시키는 공격 인프라가 되었지만, ML 엣지 장치는 더 많은 일을 할 수 있어요. 스마트 카메라는 얼굴 데이터베이스를 노출할 수 있고, 음성 비서는 대화 내용을 유출할 수 있고, 드론이나 교통 카메라는 물리 세계의 판단과 감시에 악용될 수 있어요.

따라서 엣지 ML 보안은 기본 비밀번호 제거만으로 끝나지 않아요. 장치별 고유 키, Secure Boot, TLS 1.3 이상의 암호화 통신, 상호 인증, 행동 기반 이상 탐지, 원격 격리와 업데이트 보안까지 필요해요.

4. Systematic Threat Analysis and Risk Assessment

역사적 사건에서 얻는 큰 통찰은 전통 보안 패턴이 ML에서 증폭된다는 점이에요. 이유는 ML 모델이 데이터를 학습하고, 확률적 결정을 내리고, 때로는 자율적으로 실제 시스템에 영향을 주기 때문이에요.

Stuxnet식 공급망 위험은 ML에서 데이터 포이즈닝과 백도어 모델 저장소로 나타나요. Jeep식 격리 실패는 추론 API가 안전 중요 시스템으로 이어지는 구조에서 나타나요. Mirai식 엔드포인트 무기화는 수많은 엣지 ML 장치가 감염되어 데이터 유출과 조작에 쓰이는 상황으로 확장돼요.

4.1 Threat Prioritization Framework

원문은 방어 우선순위를 가능성과 피해로 정하라고 해요.

우선순위 = 발생 가능성 x 피해 규모

정확한 수식이라기보다 의사결정 틀이에요. 보안 자원은 제한되어 있으므로, 가능성이 높고 피해도 큰 위협부터 막아야 해요.

이 프레임워크는 이후 장에서 모델 탈취, 데이터 포이즈닝, 적대적 공격을 먼저 다루고, 더 전문적인 하드웨어·인프라 공격으로 넘어가는 순서를 설명해요.

5. Model-Specific Attack Vectors

원문은 ML 특화 공격을 세 범주로 나눠요.

5.1 생명주기 관점

데이터 수집 중에는 악성 샘플이나 라벨 조작이 들어올 수 있어요. 학습 중에는 백도어가 삽입될 수 있어요. 배포 후에는 API, 모바일 앱, 모델 파일을 통해 모델 탈취가 시도될 수 있어요. 추론 중에는 적대적 입력이 모델을 속일 수 있어요.

따라서 방어도 단계별로 달라야 해요. 데이터 검증은 수집 단계에, 안전한 학습 환경은 학습 단계에, 접근 제어와 API 설계는 배포 단계에, 입력 검증은 추론 단계에 배치해야 해요.

5.2 Model Theft

모델 탈취는 모델의 기밀성을 공격해요. 공격자는 파라미터, 구조, 출력 행동을 얻어 경제적 가치를 훔치거나, 추가 공격을 준비하거나, 모델이 품고 있는 민감 정보를 추론할 수 있어요.

공격 표면은 넓어요. 공개 API, 클라우드 서비스, 온디바이스 추론 엔진, 공유 모델 저장소, 직렬화 파일이 모두 대상이에요. 특히 모델 파일이 평문 ONNX나 PyTorch 체크포인트로 저장되어 있고 접근 제어가 약하면 내부 가중치와 구조가 그대로 노출될 수 있어요.

모델 탈취의 피해는 단순 경쟁 손실을 넘어가요. 추천 모델이 유출되면 고객 행동과 사업 전략이 드러날 수 있고, 훔친 모델을 기반으로 모델 반전 공격을 수행하면 학습 데이터의 민감한 속성을 추론할 수 있어요.

5.3 Exact Model Theft

정확한 모델 탈취는 내부 구조와 학습된 파라미터를 직접 얻는 공격이에요. 공격자가 노리는 정보는 크게 세 가지예요.

방어는 모델 직렬화 포맷 보안, 런타임 API 접근 제한, 배포 파이프라인 강화, 암호화와 난독화, 무결성 검증을 조합해야 해요.

5.4 Approximate Model Theft

근사 모델 탈취는 내부를 직접 보지 않고 입력-출력 행동을 복제하는 방식이에요. 공격자는 API에 많은 쿼리를 보내고 응답을 모아 대체 모델을 학습해요. 지식 증류가 원래는 모델 압축을 위한 기법이지만, 공격자에게는 교사 모델의 행동을 훔치는 방법으로 악용될 수 있어요.

성공 여부는 두 방식으로 평가돼요.

1. 대체 모델의 정확도, 정밀도, 재현율 같은 성능이 원 모델과 비슷한가요?
2. 같은 입력에 대해 원 모델과 같은 출력, 심지어 같은 실수까지 재현하나요?

원문은 공개 API의 풍부한 출력이 누출 벡터가 될 수 있음을 강조해요. 로짓, top-k 확률, 로그 확률 같은 정보는 사용자에게는 편의 기능처럼 보이지만, 공격자에게는 내부 구조를 추정하는 단서가 될 수 있어요. 따라서 쿼리 속도 제한, 자동 추출 패턴 탐지, 출력 워터마킹, 출력 정보 제한이 필요해요.

5.5 Case Study: Tesla IP Theft

Tesla와 Zoox 사례는 모델 탈취가 이론적 API 공격만이 아니라 내부자 위협과 영업비밀 유출의 문제이기도 함을 보여줘요. 원문은 전직 직원들이 자율주행 관련 기밀 파일과 소스 코드, 이미지 인식 모델을 가져갔다는 소송 사례를 소개해요. 사건은 합의로 끝났지만, ML 모델이 큰 지적 재산이라는 점과 내부자·개발 인프라·공급망 접근이 심각한 공격 경로가 될 수 있음을 보여줘요.

5.6 Data Poisoning

데이터 포이즈닝은 학습 무결성을 공격해요. 공격자는 겉으로는 정상처럼 보이는 데이터를 학습셋에 넣어 모델이 잘못된 행동을 배우게 만들어요.

원문은 포이즈닝을 이중 최적화 문제처럼 설명해요. 모델 개발자는 훈련 데이터로 손실을 줄이려 하지만, 공격자는 포이즈닝 데이터 (D_p)를 선택해서 테스트나 표적 데이터에서 손실을 키우려 해요.

[ \max_{D_p} \mathcal{L}(f_{D \cup D_p}, D_{\text{test}}) ]

여기서 (D)는 원래 학습 데이터, (D_p)는 공격자가 섞은 악성 데이터, (f_{D \cup D_p})는 두 데이터를 합쳐 학습된 모델이에요. 표적 공격에서는 특정 입력 (x_t)와 표적 라벨 (y_t)에 대한 손실을 키우도록 바뀌어요.

[ \max_{D_p} \mathcal{L}(f_{D \cup D_p}, x_t, y_t) ]

이 수식의 의미는 어렵지 않아요. 공격자는 아주 적은 악성 데이터를 넣어 모델의 결정 경계를 자신에게 유리하게 움직이려 해요.

포이즈닝의 유형은 다음과 같아요.

Perspective API 사례는 독성 댓글 탐지 모델이 학습 데이터 조작에 의해 특정 유해 표현을 놓치게 될 수 있음을 보여줘요. 방어는 데이터 수집, 저장, 라벨링, 학습 전체를 보호해야 해요. 입력 검증, 데이터셋 무결성 확인, 출처 추적, 이상치 탐지, 강건 학습, 수동 검토가 함께 필요해요.

5.7 Adversarial Attacks

적대적 공격은 학습 후 추론 시점의 견고성을 공격해요. 공격자는 모델 내부를 완전히 몰라도 입력을 조작해 잘못된 예측을 유도할 수 있어요.

접근 수준에 따라 공격자는 세 종류로 나뉘어요.

적대적 공격은 사람이 보기에는 거의 같은 입력을 모델이 다르게 판단하게 만들어요. 원문은 이미지 분류기에서 매우 작은 픽셀 변화로도 높은 공격 성공률이 가능하며, 물리 세계에서는 작은 스티커 패치가 표지판 인식을 바꿀 수 있음을 설명해요.

5.8 Case Study: Traffic Sign Attack

2017년 연구에서는 정지 표지판에 작은 흑백 스티커를 붙여 모델이 이를 속도 제한 표지판으로 오인하게 만들었어요. 사람은 여전히 정지 표지판으로 읽을 수 있었지만, 표준 교통 표지판 분류 모델은 높은 비율로 잘못 분류했어요.

이 사례가 중요한 이유는 세 가지예요.

1. 공격이 디지털 이미지 안에서만 일어나는 것이 아니라 실제 물리 세계에서도 가능해요.
2. 사람의 직관적 인식과 모델의 결정 경계가 다를 수 있어요.
3. 자율주행처럼 안전 중요한 시스템에서는 작은 오분류가 실제 사고로 이어질 수 있어요.

따라서 적대적 공격 방어는 단순히 평균 정확도를 높이는 문제가 아니에요. 입력 검증, 이상 탐지, 런타임 모니터링, 강건 학습을 함께 설계해야 해요.

6. Hardware-Level Security Vulnerabilities

원문은 여기서 소프트웨어 중심 공격에서 하드웨어 공격으로 시야를 확장해요. ML 워크로드는 CPU, GPU, TPU, FPGA, 메모리, 펌웨어, 부트로더, 센서, 인터커넥트 위에서 실행돼요. 이 기반이 약하면 상위 소프트웨어 방어를 우회할 수 있어요.

하드웨어 공격의 특징은 아래쪽 계층에서 일어나기 때문에 탐지가 어렵고, 기존 애플리케이션 보안으로는 막기 힘들다는 점이에요.

6.1 Hardware Bugs

하드웨어도 설계 결함이 있어요. Meltdown과 Spectre는 현대 프로세서의 speculative execution 최적화가 보안 누출을 만들 수 있음을 보여준 대표 사례예요.

Speculative execution은 “아마 다음에 이 명령이 필요할 것”이라고 예상해 미리 실행하는 성능 최적화예요. 문제는 미리 실행한 흔적이 캐시 같은 미세구조 상태에 남아, 공격자가 이를 통해 보호된 메모리 정보를 추론할 수 있다는 점이에요.

ML 시스템에서는 이런 결함이 모델 파라미터, 중간 활성값, 사용자 입력, 의료 데이터 같은 민감 정보를 노출할 수 있어요. 특히 클라우드 추론처럼 여러 고객이 같은 하드웨어를 공유하는 환경에서는 cross-tenant 누출 위험이 커져요.

6.2 Physical Attacks

물리 공격은 장치 자체를 직접 조작해요. 엣지 장치, 드론, 스마트 카메라, 의료 기기, 차량 센서처럼 실제 환경에 배치된 ML 시스템은 물리 접근 가능성이 높아요.

예를 들어 드론의 내비게이션 모듈을 바꿔치기하면 비행 경로나 데이터 수집이 조작될 수 있어요. 얼굴·지문 인식 장치의 센서를 교체하면 생체 데이터가 유출될 수 있어요. 자율주행 차량의 카메라, LiDAR, 레이더를 가리거나 틀어지게 하면 모델의 주변 인식이 왜곡될 수 있어요.

하드웨어 트로이목마도 중요해요. 칩 제조나 조립 단계에서 악성 회로가 들어가면 평소에는 조용히 있다가 특정 조건에서 연산을 방해하거나 정보를 유출할 수 있어요.

6.3 Fault Injection Attacks

Fault injection은 전압, 클럭, 전자기 펄스, 온도, 레이저 같은 물리적 교란을 이용해 하드웨어 연산에 오류를 유발하는 공격이에요. 결과적으로 비트 플립, 명령 건너뛰기, 메모리 상태 손상이 생길 수 있어요.

원문은 마이크로컨트롤러에서 실행되는 DNN에 레이저 fault injection을 적용해 ReLU 활성화 함수 실행을 건너뛰게 만든 사례를 소개해요. ReLU는 대략 음수 값을 0으로 만들고 양수는 통과시키는 함수인데, 분기 명령이 교란되면 뉴런 출력이 입력과 무관하게 0으로 강제될 수 있어요.

ML에서 fault injection의 위험은 다음과 같아요.

방어는 물리적 보호, 탬퍼 탐지, 오류 정정 메모리, 안전한 펌웨어, 이상 탐지, 모델 워터마킹을 조합해야 해요. 단, 엣지 장치에서는 비용과 전력 제약 때문에 모든 방어를 넣기 어렵다는 한계가 있어요.

6.4 Side-Channel Attacks

사이드 채널 공격은 시스템이 의도치 않게 흘리는 물리 신호를 이용해 정보를 추론해요. 전력 소비, 실행 시간, 전자기파, 소리, 열 같은 신호가 단서가 될 수 있어요.

AES 같은 암호 알고리즘은 수학적으로 안전해도 실제 하드웨어 실행 과정에서 전력 패턴을 흘릴 수 있어요. 비밀번호를 한 바이트씩 확인하는 장치가 틀린 지점에서 일찍 멈춘다면, 전력 파형을 본 공격자는 “어디까지 맞았는지”를 알 수 있어요. 이렇게 탐색 공간이 줄어들면 비밀 값을 훨씬 쉽게 찾을 수 있어요.

ML에서도 같은 문제가 생겨요. 로컬 음성 인식 장치의 전력·시간 패턴이 어떤 명령을 처리하는지 드러낼 수 있고, ML 가속기의 신호가 모델 구조나 파라미터를 노출할 수 있어요. “신호가 있으면 이용될 수 있다”는 관점이 중요해요.

6.5 Leaky Interfaces

누수 인터페이스는 의도보다 많은 정보를 드러내거나 검증되지 않은 입력을 받아들이는 접근 지점이에요. 업데이트 포트, 디버그 포트, 원격 관리 포트, 진단 인터페이스가 대표적이에요.

원문은 보안이 약한 베이비 모니터, 무선 취약점이 있는 의료 기기, 생산 제품에 남겨진 디버그 포트를 예로 들어요. ML 기기에서도 유지보수용 인터페이스가 인증 없이 열려 있거나 암호화되지 않으면, 사용자 행동 패턴, 모델 파라미터, 중간 출력, 펌웨어가 노출될 수 있어요.

방어는 강한 인증, 암호화 통신, 런타임 이상 탐지, 인터페이스 목록 관리, 접근 정책, 정기 감사, 제로트러스트 원칙이에요.

6.6 Counterfeit Hardware

위조 하드웨어는 정품처럼 보이지만 품질이나 보안이 보장되지 않는 부품이에요. 복잡한 글로벌 조달망에서는 낮은 비용 압박 때문에 위조 부품이 들어올 수 있어요.

위조 부품은 빨리 고장 나거나 부하에서 예측 불가능하게 동작할 수 있고, 악성 회로나 백도어를 포함할 수도 있어요. 예를 들어 데이터센터의 복제 라우터가 모델 예측이나 사용자 데이터를 몰래 가로챌 수 있어요.

의료와 금융처럼 규제가 강한 영역에서는 위조 하드웨어가 안전, 프라이버시, 법적 책임 문제로 이어져요. 그래서 공급업체 검증과 부품 테스트가 사후 탐지보다 훨씬 중요해요.

6.7 Supply Chain Risks

공급망 위험은 위조 하드웨어보다 넓은 문제예요. ML 시스템의 부품은 설계, 제조, 조립, 유통, 통합을 거쳐요. 각 단계에서 변조, 대체, 재포장, 트로이목마 삽입이 가능해요.

특히 ML 시스템은 CPU, GPU, 메모리, 가속기 등 이질적 하드웨어를 함께 사용하므로 한 부품의 타협이 전체 시스템 신뢰를 무너뜨릴 수 있어요. 클라우드나 연합 엣지 네트워크처럼 공유 환경에서는 하드웨어 격리의 중요성이 더 커져요.

원문은 zero-trust 공급망 관행을 강조해요. 공급업체 심사, 부품 출처 검증, 탬퍼 흔적 보호, 지속 모니터링, 결함을 탐지하고 격리하는 fault-tolerant 구조가 필요해요.

6.8 Case Study: Supermicro Controversy

2018년 Bloomberg Businessweek는 Supermicro 서버 메인보드에 감시 칩이 삽입되었다는 의혹을 보도했어요. Apple, Amazon, Supermicro는 이를 부인했고, 공개적으로 검증된 기술 증거도 부족하다는 비판이 있었어요.

하지만 원문은 이 사건의 사실 여부보다 더 큰 교훈을 강조해요. 복잡한 글로벌 하드웨어 공급망은 완전히 감사하기 어렵고, 평판이 좋은 공급업체를 사용한다고 해서 하드웨어 무결성이 자동으로 보장되지는 않아요. ML 시스템은 여러 종류의 가속기와 메모리, 처리 장치에 의존하므로 하드웨어 생명주기 전체를 보안 대상으로 봐야 해요.

7. When ML Systems Become Attack Tools

지금까지는 ML 시스템이 공격받는 상황을 봤어요. 원문은 이제 관점을 뒤집어요. ML은 방어 대상일 뿐 아니라 공격을 증폭하는 도구가 될 수 있어요.

공격자는 ML을 이용해 정찰, 추론, 위장, 자동화, 회피를 수행할 수 있어요. 언어 모델은 더 그럴듯한 피싱 메시지를 만들 수 있고, 분류·클러스터링 모델은 시스템 행동 패턴을 학습해 정찰을 자동화할 수 있고, 적대적 예시 생성기는 탐지기를 우회하는 입력을 만들 수 있어요.

이 위험이 큰 이유는 확장성 때문이에요. 좋은 ML 모델이 데이터와 컴퓨팅이 늘수록 성능이 좋아지듯, 공격용 ML도 더 많은 데이터와 컴퓨팅으로 더 잘 일반화하고 더 많은 대상을 자동화할 수 있어요. 방어자는 지연 시간, 규제, 운영 제약을 지켜야 하지만 공격자는 실험 비용을 낮게 유지하며 반복할 수 있어요.

7.1 Case Study: Deep Learning for SCA

원문은 SCAAML, 즉 머신러닝 보조 사이드 채널 공격을 사례로 들어요. 전통적인 사이드 채널 공격은 전문가가 전력 파형에서 통계적 패턴을 찾아 비밀 키를 추론했어요. 딥러닝은 이 과정을 분류 문제로 바꿔요.

전력 파형 입력 -> 신경망 -> AES 중간값 또는 키 바이트 예측

연구자들은 STM32F415 마이크로컨트롤러에서 TinyAES를 실행하며 전력 trace를 수집하고, CNN을 훈련해 AES의 S-box 중간값 같은 비밀 의존 값을 예측했어요. 이 방식은 적은 수의 trace로도 128비트 키 복구가 가능함을 보였어요.

핵심 교훈은 ML이 공격자의 전문 지식 요구량을 낮추고, 노이즈나 시간 어긋남이 있는 신호에서도 패턴을 학습할 수 있게 만든다는 점이에요. 따라서 방어자는 “ML 모델을 어떻게 보호할까”뿐 아니라 “공격자가 ML을 어떻게 사용할까”도 생각해야 해요.

8. Comprehensive Defense Architectures

원문은 이제 방어로 넘어가요. 핵심 원칙은 layered defense, 즉 defense-in-depth예요. 단일 방어 수단은 실패할 수 있으므로 여러 독립 방어가 서로의 약점을 보완해야 해요.

8.1 The Layered Defense Principle

계층적 방어는 ML에서 특히 중요해요. ML 시스템은 데이터 의존성, 모델 노출, 반복 쿼리, 추론 패턴 때문에 일반 소프트웨어보다 다양한 공격 표면을 가져요.

데이터 계층은 민감 정보 노출을 줄이고, 모델 계층은 모델 탈취와 조작을 줄이고, 런타임 계층은 실행 중 공격 증상을 탐지하고, 하드웨어 계층은 상위 방어가 의존할 신뢰 기반을 제공해요.

8.2 Privacy-Preserving Data Techniques

데이터 프라이버시 기법의 공통 목표는 “학습에 필요한 통계적 패턴은 남기되, 개인 한 명에 대한 확신은 줄이는 것”이에요.

Differential Privacy

차등 프라이버시는 한 사람의 데이터가 포함되었는지 빠졌는지가 알고리즘 출력에 큰 차이를 만들지 않도록 보장해요. 인접 데이터셋 (D)와 (D’)가 한 기록만 다를 때, 무작위 알고리즘 (\mathcal{A})가 (\epsilon)-차등 프라이버시를 만족한다는 것은 다음을 뜻해요.

[ \Pr[\mathcal{A}(D) \in S] \leq e^{\epsilon}\Pr[\mathcal{A}(D’) \in S] ]

여기서 (\epsilon)은 privacy budget이에요. 작을수록 더 강한 프라이버시를 뜻하지만 더 많은 잡음이 필요해 모델 유용성이 낮아질 수 있어요. 원문은 (\epsilon = 0.1)은 강한 보호, (\epsilon = 1.0)은 중간 수준, (\epsilon = 10)은 더 약하지만 유용성을 보존하는 설정으로 설명해요.

실제로는 Laplace 또는 Gaussian 잡음을 쿼리 응답이나 모델 업데이트에 넣고, DP-SGD처럼 학습 과정의 기울기에 잡음을 추가해 개인 데이터의 영향력을 제한해요. 단, privacy budget 관리, 난수 품질, 부동소수점 구현, 반복 쿼리 누적을 조심해야 해요.

Federated Learning

연합 학습은 원본 데이터를 중앙 서버에 모으지 않고 각 클라이언트가 로컬 데이터로 업데이트를 계산한 뒤, 서버가 업데이트를 집계하는 방식이에요.

[ \theta_{t+1} \leftarrow \sum_{k=1}^{K} \frac{n_k}{n} \cdot \theta_t^{(k)} ]

여기서 (\theta_t^{(k)})는 클라이언트 (k)의 업데이트, (n_k)는 그 클라이언트의 샘플 수, (n)은 전체 샘플 수예요. 샘플이 많은 클라이언트의 업데이트가 더 큰 비중을 갖는 가중 평균이라고 보면 돼요.

연합 학습은 원본 데이터 이동을 줄이지만, 업데이트 자체에서 정보가 새어 나올 수 있어요. 그래서 안전한 집계, 차등 프라이버시, 하드웨어 보호가 함께 필요해요. 원문의 Gboard 예시는 로컬 학습, 암호화된 업데이트 업로드, 전역 집계, 새 모델 배포 흐름을 보여줘요.

Homomorphic Encryption and SMPC

동형 암호는 암호문 위에서 계산한 결과가 평문에서 계산한 결과의 암호문과 대응되도록 해요.

[ \text{Enc}(f(x)) = f(\text{Enc}(x)) ]

즉, 클라우드가 입력 내용을 몰라도 암호화된 입력에 대해 추론을 수행할 수 있어요. 다만 계산 비용이 매우 높아서 작은 모델이나 오프라인 작업에 더 적합해요.

안전한 다자간 계산(SMPC)은 여러 당사자가 각자의 입력을 공개하지 않고 공동 계산을 수행하게 해요. 병원이나 은행처럼 데이터 공유가 어려운 기관 간 공동 학습에 유용하지만, 통신과 계산 오버헤드가 큽니다.

Synthetic Data Generation

합성 데이터는 실제 데이터 분포를 배운 생성 모델로 인공 데이터를 만드는 방식이에요. 일반적인 흐름은 세 단계예요.

1. 실제 데이터 (D_{\text{real}})에서 생성 모델 (G_\theta)가 분포 (p(x))를 학습해요.
2. 무작위 잡음 (z_i)를 넣어 (G_\theta(z_i)) 형태의 합성 샘플을 만들어요.
3. 합성 데이터가 실제 데이터의 통계적 성질을 유지하면서 특정 기록을 암기하지 않는지 검증해요.

합성 데이터는 공유와 연구에 유용하지만, mode collapse로 희귀 패턴을 놓칠 수 있고, 생성 모델 자체가 실제 데이터를 암기할 위험도 있어요. 그래서 원문은 병원 예시에서 GAN으로 합성 환자 데이터를 만들되, 차등 프라이버시를 함께 적용해 암기 위험을 낮추는 방식을 설명해요.

Comparative Properties

프라이버시 기법은 강도, 오버헤드, 성숙도, 사용 사례가 달라요.

8.3 Case Study: GPT-3 Data Extraction Attack

원문은 대형 언어 모델이 학습 데이터를 그대로 누출할 수 있음을 보여준 GPT-3 데이터 추출 연구를 소개해요. 연구자들은 반복 프롬프트와 continuation 공격을 통해 이메일 주소, 전화번호, 저작권 텍스트, 필터링됐어야 할 개인정보를 추출했어요.

핵심 원인은 희귀하거나 반복된 텍스트 시퀀스의 암기예요. 큰 모델은 더 많은 파라미터를 가지므로 학습 데이터의 일부를 의도치 않게 데이터베이스처럼 저장할 수 있어요. 데이터 중복 제거만으로는 충분하지 않았고, 차등 프라이버시, 강한 PII 필터링, 멤버십 추론 방어, 기계적 언러닝, 정기적 암기 감사가 필요하다는 산업적 반응으로 이어졌어요.

8.4 Secure Model Design

모델 보안은 배포 후에만 붙이는 것이 아니에요. 설계 단계에서부터 모델이 불확실한 입력에 과신하지 않도록 해야 해요.

대표 설계 전략은 다음과 같아요.

키워드 스포팅 예시를 보면, 음성 활성화 모델은 작은 CNN, confidence calibration, abstention threshold를 사용해 불확실한 음성에 반응하지 않도록 설계할 수 있어요. 또한 특정 비공개 오디오 트리거에만 고유 라벨을 내도록 워터마크를 심으면 모델 도용 여부를 나중에 검증할 수 있어요.

8.5 Secure Model Deployment

배포 보안은 모델이 어떻게 저장, 패키징, 접근되는지에 집중해요. 모델을 평문 파일로 저장하면 파일 시스템이나 메모리에 접근한 공격자가 가중치와 구조를 훔칠 수 있어요.

안전한 배포는 다음을 포함해요.

API 키를 코드에 하드코딩하지 않고 환경 변수나 안전한 secret 관리 시스템에서 읽는 것도 기본이에요. 키가 로그나 버전 관리에 노출되면 모델 추출과 비용 남용으로 이어질 수 있어요.

8.6 Runtime System Monitoring

런타임 모니터링은 배포 후에도 시스템을 계속 관찰하는 방어예요. 정적 방어만으로는 충분하지 않아요. 공격자는 입력을 조금씩 바꾸고, API를 탐색하고, 모델 행동의 약점을 찾기 때문이에요.

Input Validation

입력 검증은 모델 앞단의 방화벽이에요. 입력 크기, 타입, 값 범위, 해상도, 채널 수, 샘플링 레이트 같은 낮은 수준의 검사부터, 얼굴이 실제로 있는지, 음성이 포함되는지 같은 의미 검사까지 포함해요.

생성 모델에서는 프롬프트 필터링도 입력 검증이에요. 금지어, 상표명, 유해한 의료 주장, 불법 요청을 키워드, 정규식, 경량 분류기로 걸러요. 또한 입력 데이터가 학습 분포와 통계적으로 비슷한지도 볼 수 있어요.

Output Monitoring

출력 감시는 모델이 낸 답이 이상하지 않은지 관찰해요. 예측 확신도, 엔트로피, 클래스 분포, 응답 패턴을 추적해 평소와 다른 행동을 탐지해요.

예를 들어 콘텐츠 조정 모델이 유해한 입력에 갑자기 높은 확신으로 “안전”이라고 답한다면 우회 공격이나 데이터 분포 변화일 수 있어요. 생성 이미지 모델은 프롬프트가 안전해 보여도 출력물이 정책을 위반할 수 있으므로, 생성 후 안전 분류기로 폭력, 노출, 브랜드 오용 등을 검사해야 해요.

언어 모델에서는 독성, 환각, 문맥 이탈, 잘못된 형식, 불법 콘텐츠를 감시해요. 문제가 있으면 재작성, 스크립트형 fallback, 응답 중단, 사람 검토로 이어질 수 있어요.

Integrity Checks

무결성 검사는 실행 중인 모델과 환경이 원래 의도한 것인지 확인해요. 모델 로드 전에 SHA-256 같은 해시를 계산해 서명된 기준값과 비교할 수 있어요.

또한 모델 파일 접근 권한을 제한하고, 비정상 경로에서 체크포인트를 반복 읽는 시도나 승인되지 않은 IP의 추론 요청을 감시해야 해요. 컨테이너나 VM 격리도 도움이 되지만, 설정 오류와 공급망 취약점으로 약해질 수 있으므로 지속 검증이 필요해요.

규제 의료 ML 예시에서는 서명된 manifest와 모델 해시 확인, 승인된 Python 패키지 사용 확인, 서명·attestation된 VM에서만 추론 수행 같은 검사가 필요해요.

Response and Rollback

이상이나 침해가 탐지되면 빠르게 대응해야 해요. ML 시스템은 일반 소프트웨어와 달리 모델 상태, 데이터 드리프트, 추론 행동까지 복구 대상이 되므로 대응이 더 복잡해요.

대응 흐름은 다음과 같아요.

탐지 기준 초과
  -> 자동/반자동 대응 시작
  -> 모델 격리 또는 트래픽 제한
  -> 마지막 정상 모델로 롤백
  -> 로그, 파라미터 변화, 메모리 스냅샷 분석
  -> 안전한 데이터와 서명된 아티팩트로 재학습/패치
  -> 사후 리뷰로 테스트와 모니터링 기준 개선

예를 들어 새 사기 탐지 모델이 갑자기 거래를 잘못 분류하면, 마지막 정상 체크포인트로 되돌리고 문제 버전은 격리해 분석해요. 공개 API가 대량 탐색을 받으면 IP 단위 속도 제한이나 차단을 적용할 수 있어요.

8.7 Hardware Security Foundations

소프트웨어 방어는 하드웨어와 펌웨어가 신뢰할 수 있다는 가정 위에 있어요. 공격자가 OS를 장악하거나 프로세서 취약점을 이용하거나 물리 접근을 얻으면 소프트웨어 방어는 우회될 수 있어요. 그래서 하드웨어 root of trust가 필요해요.

Hardware-Software Co-Design

하드웨어 보안은 공짜가 아니에요. ARM TrustZone 전환, 암호 연산, Intel SGX context switching, TEE 메모리 제한은 지연 시간, 전력, 모델 크기 제약을 만들어요.

예를 들어 작은 양자화 모델은 TEE 안에서 실행 가능할 수 있지만, 큰 ResNet 계열 모델은 보호 메모리 제한 때문에 모델 분할이나 별도 메모리 관리가 필요할 수 있어요. 동형 암호는 강한 프라이버시를 주지만 계산 오버헤드가 매우 커서 작은 모델이나 오프라인 작업에 더 적합해요.

즉 보안 수준, 모델 크기, 지연 시간, 전력, 비용은 함께 설계해야 해요.

Trusted Execution Environments

TEE는 프로세서 안의 하드웨어 격리 실행 영역이에요. 운영체제나 일반 애플리케이션이 손상되어도 TEE 내부의 코드와 데이터는 보호되도록 설계돼요.

TEE가 제공하는 주요 속성은 네 가지예요.

ML에서는 생체 인식 입력, 모델 파라미터, 중간 계산, 최종 예측을 보호하는 데 쓰일 수 있어요. Apple Secure Enclave, ARM TrustZone, Intel SGX가 대표 사례예요. Face ID 예시처럼 얼굴 임베딩 모델과 생체 템플릿을 하드웨어 격리 영역에서 처리하면, 주 운영체제가 손상되어도 민감 정보가 밖으로 나가지 않게 할 수 있어요.

하지만 TEE는 메모리 제한, context switching 오버헤드, 개발 복잡도, 인증 비용, 에너지 소비, 분산 워크로드 조율 문제를 가져요. 따라서 위협 모델이 충분히 높은 상황에서 선택적으로 적용해야 해요.

Secure Boot

Secure Boot는 기기가 시작될 때 부트로더, 커널, 운영체제, 펌웨어, 때로는 모델 바이너리까지 서명 검증을 거쳐 승인된 구성요소만 실행되도록 하는 메커니즘이에요.

ML 엣지 시스템에서 부팅 과정이 손상되면 모델 런타임이 시작되기 전부터 가중치 가로채기, 학습 데이터 변조, 추론 결과 우회가 가능해요. Secure Boot는 초기 명령부터 신뢰 체인을 만들고, 서명 검증이 실패하면 실행을 멈춰요.

Apple Face ID 사례에서 Secure Enclave 펌웨어는 Apple 서명으로 검증되고, 검증된 뒤에야 얼굴 인식 처리가 진행돼요. 얼굴 데이터는 디스크에 저장되거나 외부로 전송되지 않고 enclave 안에서 처리돼요. 업데이트 역시 서명된 펌웨어와 모델만 허용해 신뢰 체인을 유지해요.

단점도 있어요. 키 발급, 회전, 폐기 관리가 어렵고, 부팅 시 서명 검증 지연이 생기며, 모든 구성요소가 정확히 서명되어야 해요. 벤더 잠금과 사용자 커스터마이징 제한도 논쟁점이에요.

Hardware Security Modules

HSM은 키 생성, 서명, 암호화, 복호화 같은 암호 연산을 안전하게 수행하는 탬퍼 저항 하드웨어예요. 금융, 국방, 클라우드 인프라에서 오래 쓰였고, ML 파이프라인에서도 모델 서명, 키 관리, 데이터 암호화, 규제 준수에 중요해요.

ML에서 HSM은 다음을 보호해요.

하지만 HSM은 비싸고, 공간과 전력, 지연 시간, API 통합, 대규모 장치 키 프로비저닝, 인증 절차의 부담이 있어요. 고보증 환경에서는 가치가 크지만, 저가형 임베디드 제품에는 부담이 될 수 있어요.

Physical Unclonable Functions

PUF는 반도체 제조 과정에서 자연스럽게 생기는 미세한 물리적 차이를 이용해 장치 고유 응답을 만드는 기술이에요. 전통적인 키처럼 메모리에 저장하는 대신, 칩의 물리적 fingerprint에서 키나 인증 응답을 만들어내요.

PUF는 challenge-response 방식으로 동작해요.

challenge 입력 -> 칩의 물리적 미세 차이 -> device-unique response

ML 엣지 장치에서는 PUF로 장치별 키를 만들고, 모델을 해당 장치에서만 복호화되게 할 수 있어요. 드론이 클라우드 서버에 연결할 때도 PUF 응답으로 “이 장치가 진짜인지” 증명할 수 있어요.

한계도 있어요. 온도와 전압 변화 때문에 응답에 오류가 생길 수 있어 error correction이 필요하고, challenge-response 쌍 관리와 폐기 문제가 있어요. 또한 PUF 응답 구조가 외부에 많이 노출되면 ML 기반 모델링 공격으로 복제될 위험도 있어요.

Mechanisms Comparison

하드웨어 보안 메커니즘은 서로 다른 역할을 맡아요.

이들은 함께 사용할 때 더 강해요. Secure Boot가 초기 신뢰를 만들고, TEE가 런타임을 격리하고, HSM이 키를 보호하고, PUF가 장치 고유 신원을 제공하는 식이에요.

9. Practical Implementation Roadmap

원문은 모든 방어를 한 번에 넣지 말고 단계적으로 구현하라고 해요. 조직의 위협 모델과 역량에 맞춰 차근차근 성숙도를 높이는 접근이에요.

9.1 Phase 1: Foundation Security Controls

1단계는 가장 기본적인 통제예요. 가장 흔한 공격을 줄이고, 이후 고급 방어가 의존할 기반을 만들어요.

9.2 Phase 2: Privacy Controls and Model Protection

2단계는 민감 데이터와 모델 지적 재산을 보호해요.

9.3 Phase 3: Advanced Threat Defense

3단계는 고위험 환경과 고급 공격자를 대비해요.

9.4 Implementation Considerations

로드맵은 고정된 순서표가 아니라 조정 가능한 기준이에요. 의료 시스템은 프라이버시와 규제 준수를 먼저 강화할 수 있고, 금융 시스템은 데이터 보호와 모델 탈취 방어를 중시할 수 있으며, 자율주행 시스템은 적대적 견고성을 빠르게 강화해야 할 수 있어요.

단계가 올라갈수록 전문성, 비용, 운영 복잡도가 증가해요. Phase 1은 일반 IT 보안 역량으로도 시작할 수 있지만, Phase 3은 ML 보안 전문 지식, red team 훈련, 특화 감사가 필요할 수 있어요.

10. Fallacies and Pitfalls

10.1 Fallacy: Security through obscurity is enough

모델 구조나 구현을 숨기면 안전하다고 생각하는 것은 위험해요. 현대 공격은 모델 내부를 몰라도 입력-출력 행동을 쿼리해 모델을 복제하거나 적대적 예시를 전이시킬 수 있어요. 좋은 보안은 공격자가 시스템을 어느 정도 안다고 가정해도 버텨야 해요.

10.2 Pitfall: Differential privacy automatically solves privacy

차등 프라이버시는 강력하지만 자동 해결책은 아니에요. (\epsilon) 설정이 부적절하면 보호가 약하거나 모델 유용성이 크게 떨어질 수 있어요. 난수 생성, 부동소수점 구현, 반복 쿼리로 인한 budget 소진도 실제 보장을 무너뜨릴 수 있어요.

10.3 Fallacy: Federated learning inherently guarantees privacy

연합 학습은 원본 데이터를 중앙 서버로 보내지 않지만, gradient와 모델 업데이트는 정보를 누출할 수 있어요. 공격자는 업데이트에서 학습 예시를 복원하거나 멤버십을 추론할 수 있어요. 그래서 안전한 집계와 차등 프라이버시가 함께 필요해요.

10.4 Pitfall: Security as an isolated component

보안을 개별 부품에만 붙이면 시스템 전체 공격을 놓쳐요. 데이터 수집, 학습, 모델 레지스트리, 배포, API, 모니터링 사이의 연결부가 공격 경로가 될 수 있어요. 보안은 ML 파이프라인 전체 속성으로 설계되어야 해요.

10.5 Pitfall: Underestimating distributed attack surfaces

분산 ML은 공격 표면을 줄이기보다 늘리는 경우가 많아요. 여러 데이터센터의 gradient 교환, 인증서 위조, 훈련 라운드의 무단 참여, 엣지 장치 업데이트, 멀티클라우드 모델 서빙, 모델 레지스트리, 로드밸런서, 모니터링 시스템이 모두 잠재적 진입점이에요.

따라서 분산 ML 보안은 네트워크 통신 보안, 엔드포인트 강화, 도메인 간 identity 관리, 정책 조율까지 포함해야 해요.

11. Summary

이 장의 결론은 분명해요. 보안과 프라이버시는 ML 시스템의 부가 기능이 아니라 배포 가능성과 사회적 신뢰를 결정하는 핵심 요구사항이에요.

ML 시스템은 모델 기밀성, 학습 무결성, 추론 견고성, 데이터 프라이버시, 하드웨어 신뢰성이라는 여러 축에서 공격받을 수 있어요. 역사적 보안 사고는 공급망 오염, 격리 실패, 엔드포인트 무기화가 ML 환경에서 더 큰 위험으로 증폭될 수 있음을 보여줘요.

효과적인 방어는 계층적이어야 해요. 데이터 계층에서는 차등 프라이버시와 연합 학습을, 모델 계층에서는 안전한 설계와 워터마킹을, 런타임 계층에서는 입력 검증과 출력 감시를, 하드웨어 계층에서는 TEE, Secure Boot, HSM, PUF를 고려해요. 그리고 이 모든 방어는 비용, 정확도, 지연 시간, 운영 복잡도와의 trade-off 속에서 선택해야 해요.

복습 질문

1. 보안과 프라이버시는 어떤 점에서 다르고, 어떤 상황에서 서로 충돌할 수 있나요?
2. ML 시스템이 일반 소프트웨어보다 민감 정보를 더 오래 품을 수 있는 이유는 무엇인가요?
3. Stuxnet, Jeep Cherokee 해킹, Mirai 봇넷은 각각 ML 보안에 어떤 교훈을 주나요?
4. 데이터 포이즈닝, 모델 탈취, 적대적 공격은 ML 생명주기의 어느 단계에서 주로 발생하나요?
5. 정확한 모델 탈취와 근사 모델 탈취는 어떻게 다른가요?
6. 데이터 포이즈닝을 (D_p)를 선택하는 최적화 문제로 볼 수 있는 이유는 무엇인가요?
7. 적대적 예시가 사람에게는 거의 정상처럼 보이면서도 모델을 속일 수 있는 이유는 무엇인가요?
8. Meltdown과 Spectre 같은 하드웨어 버그가 ML 시스템의 개인정보와 모델 자산에 왜 위험한가요?
9. 사이드 채널 공격은 소프트웨어 취약점을 직접 이용하지 않고도 어떻게 정보를 추론하나요?
10. ML이 공격 대상이 아니라 공격 도구가 될 수 있다는 말은 무슨 뜻인가요?
11. 차등 프라이버시의 (\epsilon) 값이 작아질수록 어떤 장점과 단점이 생기나요?
12. 연합 학습은 왜 원본 데이터를 보내지 않아도 완전한 프라이버시 보장이 되지는 않나요?
13. 입력 검증과 출력 모니터링은 각각 어떤 종류의 런타임 위험을 줄이나요?
14. TEE, Secure Boot, HSM, PUF는 각각 하드웨어 신뢰 기반에서 어떤 역할을 하나요?
15. 이 장의 3단계 구현 로드맵을 여러분의 조직이나 프로젝트에 적용한다면, 어떤 단계를 먼저 강화해야 할까요?