Security Crash Test Practical Security Evaluations of Automotive Onboard IT Components

1. Security Analysis aNd Evaluation Lab
Name 이 상 민
Security Crash Test
PracticalSecurityEvaluationsof
AutomotiveOnboardITComponents
2017. 3. 10

2. 2
 저자
 Stephanie Bayer, Thomas Enderle, Dennis Kengo Oka,
Marko Wolf
 상세정보
 발행처 : Automotive-Safety & Security
 발행 년도 : 2014
1. Introduction
2. Automotive Security Threats
3. Embedded Security Evaluation
3. Theoretical Automotive
Security Analyses
3. Practical Automotive
Security Testing
3. Verifiable Automotive
Security Certifications
4. Automotive Security
Evaluation Assurance Levels

3. 3
 저자
 Stephanie Bayer, Thomas Enderle, Dennis Kengo Oka,
Marko Wolf
 상세정보
 발행처 : Automotive-Safety & Security
 발행 년도 : 2014
1. Introduction
2. Automotive Security Threats
3. Embedded Security Evaluation
3. Theoretical Automotive
Security Analyses
3. Practical Automotive
Security Testing
3. Verifiable Automotive
Security Certifications
4. Automotive Security
Assurance Levels

4. 4
 서론
 차량의 안전성(Safety)을 다루는 연구는 수십년 째 정립되어
수행되고 있음
 하지만 소프트웨어 기반의 IT 컴포넌트(인포테인먼트, CAN
Network)가 차량의 주요 구성 요소가 되어 보안성(Security)에
대한 중요도가 상승
1. Introduction
*ISO 26262 : 차량의 기능 안전성(validation)에 대한 국제 표준. 차량에 탑재되는
E/E(Electric & Electronic) 시스템의 오류로 인한 사고 방지를 목적으로 함
기존의 차량에 대한 평가 방법
안전성(Safety)를 위한 기능 시험
예) *ISO 26262

5. 5
 서론
 차량 IT 컴포넌트에 대한 이론적인 보안 분석(Theoretical Security
Analysis) 연구와 실제 보안 시험(Practical Security Testing)에
대한 연구는 초기 단계
 따라서 두 가지 분석 방법을 기반으로 차량 IT 컴포넌트의 체계적인
평가를 위한 ASEAL(Automotive Security Evaluation Assurance
Levels) 제안
1. Introduction
ASEAL
(Automotive Security Evaluation Assurance Levels)
Theoretical Automotive
Security Analyses
Practical Automotive
Security Testing
저자가 제안하는 체계적인 평가 방법
평가 클래스 도출

6. 6
 예) ASEAL (Automotive Security EAL)
1. Introduction

7. 7
 Theoretical Security Analysis, Practical Security Testing
 차량을 대상으로 하는 실제 공격을 막기 위해서는 Practical Security
Testing이 반드시 필요
 안전한(Security) 소프트웨어를 개발하기 위해서는 소프트웨어 개발 생명
주기의 각 단계에 적절한 보안 활동을 적용하는 것이 필요*
 발생할 수 있는 위협을 초기에 식별 및 수정함으로써 개발과정 및 유지보수
과정에서 총 개발 비용을 줄일 수 있음
1. Introduction
설계요구사항 도출 구현 검증 배포
소프트웨어 개발 생명주기
- Theoretical Security Analysis
• Threat Risk Modeling
• Design Analysis
- Practical Security Testing
• Static, Dynamic Analysis
• Penetration Testing
*Microsoft SDL(Security Development Lifecycle)

8. 8
 Theoretical Security Analysis, Practical Security Testing
 차량을 대상으로 하는 실제 공격을 막기 위해서는 Practical Security
Testing이 반드시 필요
 안전한(Security) 소프트웨어를 개발하기 위해서는 소프트웨어 개발 생명
주기의 각 단계에 적절한 보안 활동을 적용하는 것이 필요*
 발생할 수 있는 위협을 초기에 식별 및 수정함으로써 개발과정 및 유지보수
과정에서 총 개발 비용을 줄일 수 있음
1. Introduction
설계요구사항 도출 구현 검증 배포
소프트웨어 개발 생명주기
- Theoretical Security Analysis
• Threat Risk Modeling
• Design Analysis
- Practical Security Testing
• Static, Dynamic Analysis
• Penetration Testing
*Microsoft SDL(Security Development Lifecycle)
ASEAL
(Automotive Security Evaluation Assurance Levels)

9. 9
 차량에서 발생할 수 있는 잠재 위협
 차량에서 발생하는 위협을 이해하기 위해서는 차량의 고유 기능(핸들,
브레이크, …)을 잘 알고있어야 함
(1) 와이퍼, 라이트와 같은 기능 조작
(2) 주행 거리계 조작
(3) ECU에 저장된 차량 정보 유출 및 조작
(4) 차량 위치 정보 조작
 이러한 위협은 Bluetooth, Wi-Fi를 이용한 원격 공격이나 OBD port, USB,
ECU와 같은 물리적 접근을 이용한 로컬 공격으로 발생 가능
2. Automotive Security Threats

10. 10
3. Embedded Security Evaluation

11. 11
3-1. Theoretical Automotive Security Analyses
 Theoretical Security Analyses은 설계 문서를 기반으로 차량
IT 컴포넌트의 보안 취약점을 분석하고 식별
 검증 수준과 사용 가능한 문서에 따라 보다 높은 수준의 설계
분석 및 심층적인 위협/위험 분석 가능
3. Embedded Security Evaluation
설계요구사항 도출 구현 검증 배포
(1) Design Analysis, Threat Risk Modeling
설계 문서
(2) 설계상 보안 위협 도출 및 수정

12. 12
3-1. Theoretical Automotive Security Analyses
 Theoretical Automotive Security Analyses에는
Design Analysis와 Threats and Risks Analysis 존재
 Design Analysis
 설계 문서 분석을 통해 개발 초기 단계에서 시스템의 체계적인 결함 식별
가능
 Threats and Risks Analysis
 설계 문서 분석을 통해 시스템의 잠재적인 보안 위협 식별 가능
(해당 단계는 Design Analysis와 유사)
 Threat Risk Analysis를 통해 재산적, 물리적 피해 및 공격의 어려움과
같은 지표로 고 위험도를 가진 위협을 찾을 수 있고 이러한 위험도가 높은
위협부터 우선 해결하는 것은 중요!
3. Embedded Security Evaluation

13. 13
 Threat Risk Modeling vs Design Analysis
3. Embedded Security Evaluation
출처 : Microsoft SDL

14. 14
3-1. Theoretical Automotive Security Analyses
 문서가 충분하지 않은 경우 보안 위협의 식별이 불가
 명세와 다르게 잘못 구현한 경우 구현 상의 취약점 식별이 불가
 차량 개발 전체 프로세스에 대한 보안 소프트웨어 개발이 필요하
기 때문에 Practical Automotive Security Testing 단계에서
구현 및 검증 단계의 취약점 식별 및 대응방안 도출이 필요
3. Embedded Security Evaluation
설계요구사항 도출 구현 검증 배포

15. 15
3-2. Practical Automotive Security Testing
 Practical Automotive Security Testing은 4가지 방법으로 구성
① Functional Security Testing
② Vulnerability Scanning
③ Fuzzing
④ Penetration Testing
 (1)번 Functional Security Testing은 기능이 명세에 따라 잘
동작 하는지(validation check)를 검증하기 위해 수행
 (2)~(3)번은 알려진 취약점(1-day), 새로운 취약점(0-day)에
의해 우회되지 않는지(verification check)를 검증하기 위해 수행
3. Embedded Security Evaluation

16. 16
3-2. Practical Automotive Security Testing
3. Embedded Security Evaluation

17. 17
3-2. Practical Automotive Security Testing
① Functional Security Testing
 대상
 Performance (성능)
 Correctness (명세에 따라 동작하는지)
 Robustness (실행 중 발생하는 에러에 잘 대응 하는지)
 Is there a bottle neck?
예) 차량 IT 컴포넌트에 포함된 랜덤 생성기가 현재 하드웨어 스펙에서
제대로 동작하는가?
3. Embedded Security Evaluation

18. 18
3-2. Practical Automotive Security Testing
3. Embedded Security Evaluation

19. 19
3-2. Practical Automotive Security Testing
② Vulnerability Scanning
 대상
 Interfaces
 Configurations
 Known Exploits
 Malware
 알려진 취약점을 찾는 것이므로 새로운 취약점을 지속적으로 업데이트
(Attack Library)
 알려진 취약점 스캐닝(Known Exploits) 방법
(1)소프트웨어, 펌웨어 코드의 정적 및 동적 분석을 통한 취약점 스캐닝
(2)열린 포트, 이용 가능한 서비스 및 인터페이스를 통한 취약점 스캐닝
(3)전체 시스템의 구성(설계)을 분석하여 취약점 스캐닝
3. Embedded Security Evaluation

20. 20
3-2. Practical Automotive Security Testing
② Vulnerability Scanning
3. Embedded Security Evaluation
도구명 설명 비용
Nessus
• 통합(시스템, 네트워크, 웹) 취약점
스캐너
상용
Heartbleed
Scanner
• HeartBleed 취약점 스캔 무료
IoT Cube
• 웹 취약점 분석의 경우 안전하지 않은 프
로토콜(SSL) 버전의 사용 여부 점검
무료
OpenVAS
• 시스템의 관리상의 취약점을 스캔 (열린
포트, OS fingerprinting)
무료
Acunetix
• 웹 취약점 스캐너로 SQL injection, XSS,
CSRF와 같은 취약점을 스캔
상용

21. 21
3-2. Practical Automotive Security Testing
3. Embedded Security Evaluation

22. 22
3-2. Practical Automotive Security Testing
③ Fuzzing
 종류
 White-box Fuzzing (ex. Symbolic Execution – Tool : SAGE)
 Black-box Fuzzing (ex. Taint Analysis(*DBI) – Tool : PIN)
 Grey-box Fuzzing (ex. Smart Fuzzing – Tool : AFL, LibFuzzer)
 입력 가능한 경로(Code Coverage)로 임의의 값을 생성 및 입력하여
수행
 차량 내부 네트워크도 사실상 작은 컴퓨터와 같기 때문에 Fuzz Testing
가능
3. Embedded Security Evaluation
*DBI : Dynamic Binary Instrumentation

23. 23
3-2. Practical Automotive Security Testing
③ Fuzzing
3. Embedded Security Evaluation
도구명 설명
PIN
 장점
• 입력 값을 처리하는 모든 행동(함수 호출, 레지스터 값)의
식별 및 변조 가능
 단점
• 너무 느린 속도
AFL
 장점
• 입력 값을 변경하여 Code Coverage를 넓히는
Smart Fuzzer
• Security Testing에서 가장 활발히 사용
• Heartbleed 발견(LibFuzzer)
 단점
• 사용자가 직접 Mutation 범위 지정
(대상 시스템 구조의 이해 정도에 따라 결과가 상이)
LibFuzzer

24. 24
3-2. Practical Automotive Security Testing
3. Embedded Security Evaluation

25. 25
3-2. Practical Automotive Security Testing
④ Penetration Testing
 대상
 Hardware
 Software
 Network
 Organization
 분석가의 경험에 의존한 모의 해킹 수행
(이전 (1)~(3)단계의 결과 사용 가능)
 Penetration Testing은 세 가지 방법으로 수행 가능
 White-box Pen Testing
 Black-box Pen Testing
 Grey-Box Pen Testing
 하드웨어, 소프트웨어 및 네트워크 뿐만 아니라 조직에 대한 사회
공학 공격도 포함
3. Embedded Security Evaluation

26. 26
3-2. Practical Automotive Security Testing
 앞서 언급한 4가지 방법 중 특히 3, 4번은 시간과 자원에 의존적
 따라서 Practical Security Testing은 Theoretical Security
Analysis를 대체할 수 없음
 Theoretical Security Analysis와 Practical Security Testing은
상호 보완 관계
3. Embedded Security Evaluation
두 가지 방법의 단점
Theoretical Security Analysis Practical Security Testing
• 문서가 충분하지 않은 경우 위협 식별
불가
• 명세와 다르게 구현한 경우 구현 상의
취약점 식별 불가
• Fuzz Testing, Pen Testing은 시간과 자원
에 의존적

27. 27
3-3. Verifiable Automotive Security Certifications
 차량 IT 컴포넌트의 보안성을 보증하기 위해서는 Theoretical
Security Analysis, Practical Security Testing이 필요
 위 과정에서 도출된 결과를 토대로 보안성 평가를 수행하고 평가
대상이 특정 등급에 해당하는 최소 보안 요구사항을 가졌음을
보증
 동일 분야의 서로 다른 제품 간 보안성 비교 가능
 소비자에게 신뢰 제공
3. Embedded Security Evaluation

28. 28
 ASEAL을 제안
 ASEAL(Automotive Security Evaluation Assurance
Levels)이란?
 목적 : 차량 Onboard IT Components를 대상으로 최소 보안 수준을
보증하여 평가 결과를 통한 제품의 보안성 비교 및 소비자 신뢰 제공
 평가는 ‘범위(Scope)’와 ‘얼마나 자세히(deeply) 수행’하는지로 구성
4. Automotive Security Assurance Levels
Scope Deeply
Class of CC
Components
of CC

29. 29
 앞선 표는 일반적인 아이디어를 보여주는 전체적인 설명
 (yet incomplete)
4. Automotive Security Assurance Levels

30. 30
 TRA in Theoretical Security Analyses
 ASEAL A : TRA 1 - 공격자 모델링 및 공격의 경로 정형화되지 않은 분석
 ASEAL B : TRA 2 – TRA 1 + 모든 알려진 차량 보안 공격에 대해 위험도를 포함한
Attack Tree 완성
 ASEAL C : TRA 3 – TRA 2 + Darknet 조사 및 잠재적인 공격 경로의 위험도 연구를 포
함한 검증(CC EAL 4)
 ASEAL D : TRA 4 – TRA 3 + 준 정형화 시험 및 검증(CC EAL 5/6)
4. Automotive Security Assurance Levels

31. 31
 DEP in Theoretical Security Analyses
 ASEAL A : -
 ASEAL B : DEP 1 - 초기 설정 분석, 초기 보안 설정
 ASEAL C : DEP 2 - 생산, 유지 및 변경 절차
 ASEAL D : DEP 3 - 폐지, 비활성화 절차
(암호 알고리즘, 암호 키를 대상으로 함)
4. Automotive Security Assurance Levels

32. 32
 SYF in Practical Security Testing
 ASEAL A : -
 ASEAL B : SYF 1 – 모든 표준 통신 프로토콜 및 외부 인터페이스에 대한
퍼징
 ASEAL C : SYF 2 – SYF 1 + Unknown Protocol에 대한 퍼징
 ASEAL D : SYF 3 – 모든 통신 프로토콜 및 인터페이스에 대한 extended
Fuzzing(evolutionary fuzzing)
4. Automotive Security Assurance Levels

33. 33
 IPA in Practical Security Testing
 ASEAL A : -
 ASEAL B : -
 ASEAL C : IPA 1 – JTAG, mem dump, Input/output 조작과 같은 기본적인 침투
및 모의 해킹 수행
 ASEAL D : IPA 2 – IPA1 + side-channel, fault injection과 같은 침투 테스트 및
물리적 공격 수행
4. Automotive Security Assurance Levels

34. 34
 ASEAL과 EAL(CC)의 차이점
 (i) 일반적인 차량 보안 위협 사례를 기반으로 보안 요구 사항을
제공
 (ii) 가능한 모든 차량 보안 위협으로부터 보호를 위해 최소한의
보안 요구 사항으로 제한
4. Automotive Security Assurance Levels
EAL(CC) ASEAL
평가 대상
(*TOE)
보안 기능이 있는 IT 제품 차량 Onboard IT Component
보증 레벨 EAL 1~7 ASEAL A~D
보안 요구 사항
최소한의 보안 요구사항
제공
최소한의 보안 요구사항
제공
*TOE : Target of Evaluation

35. 35
 기존의 Theoretical Security Analysis와 Practical
Security Testing을 더하여 ASEAL을 제안
 ASEAL을 통해 차량 Onboard IT Components의 최소
보안 수준을 보증 가능
 미래에는 신제품의 법적 책임 요구사항을 만족하고, 다양한
자동차 산업 모델을 보호하기 위해 *ISO 26262와 같이 표준
화된 방법론이 당연해 질 것으로 예측
=> OEMs, 공급자들, 보안 전문가들의 노력이 필요
6. Conclusion
*ISO 26262 : 차량의 기능 안전성(validation)에 대한 국제 표준. 차량에 탑재되는
E/E(Electric & Electronic) 시스템의 오류로 인한 사고 방지를 목적으로 함

36. Security Analysis aNd Evaluation Lab
Name 이 상 민
Security Crash Test
PracticalSecurityEvaluationsof
AutomotiveOnboardITComponents
2017. 3. 10

37. 37
질문
1. 최근 ISO 26262에는 기존의 Safety 뿐만 아니라 Security도 포함되었다고
들었던 기억이 있다. 현재 ISO 26262에 Security도 포함되는가?
2. 본 논문은 차량 Onboard IT Component를 대상으로 하는데, 본문에는 해당
Component의 범위가 나와있지 않다. 정확히 어떤 것이 평가대상(TOE)인가?
3. 저자가 제안한 ASEAL에서 각 클래스가 어떤 기준으로 도출되었는가?
4. 저자가 제안한 ASEAL의 각 클래스 별 구분된 컴포넌트는 어떤 기준으로
도출되었는가?
5. 저자가 Practical Security Testing에서 Fuzz Testing을 따로 분류한 이유가
무엇인가?
6. Design Analysis의 목표는 무엇인가?
7. 저자가 CC를 기반으로 제안한 ASEAL의 각 클래스 별 구분된 컴포넌트가 있다.
이러한 컴포넌트의 요구사항을 모두 만족하면 CC(Common Criteria)의 EAL
수준에 맞는 보안성을 보증할 수 있다고 생각하는가? 왜 그렇게 생각하는가?
8. 저자가 제안한 ASEAL의 PenTesting은 LPA, IPA, OPA의 세 가지 클래스로
다시 분류된다. 이러한 세가지 클래스의 차이점은 무엇인가?
9. 본 논문 스터디를 통해 연구실 과제 수행 시 Fuzz Testing을 수행할 것인가?
수행한다면 어떤 Fuzzing 도구를 사용할 것인가?
10. 나도(질문자) 읽어보았지만 저자가 제안한 ASEAL의 근거가 명확하지 않다. 본
논문을 심층적으로 분석하여 개선점을 도출하면 좋은 논문이 될 것 같다.