UNR No.155 - Annex 5 / 보안 솔루션

용어

AUTOSAR(AUTomotive Open System ARchtecture)

- 전 세계 차량 제조사, 부품사, 툴 및 소프트웨어 공급업체가 차량 소프트웨어 개발을 위해 조직한 개발 파트너십

 

SecOC (Secure on-board communication)

- 오토사 사양으로 캔 기반 안전한 통신을 위한 보안 모듈

 

CAN-IDS (Controller Area Network - Intrusion Detection System)

- 캔 기반 네트워크 이상 탐지 솔루션

 

HSM (Hardware Security Module) / SHE (Secure Hardware Extension)

- 독립적인 코어, 램, 롬 공간을 가지고 암호화 키를 안전하게 보관하고 빠르게 암/복호화 기능을 돕는 MCU on-chip 형태의 보안 제품

 

TARA

- 아이템에 존재하는 위협을 분석하고 위험을 정량화하기 위한 위험 평가 방법론

 

VSOC (Vehicle Security Operations Center)

- 다양한 차량으로부터 수신한 이상 탐지 로그를 분석하고 차량의 보안을 통합 관리하는 백엔드 인프라

---

UN Regulation No.155 부속서 5

위험 평가(TARA) 시 고려되어야 할 최소한의 위협과 완화방안 제시

[위협]: Part A -> [완화방안]: Part B, C

 

Part A

- 위협, 취약점, 공격 방법에 대한 기준 제시

- 7개의 카테고리, 67개의 세부 취약점/공격 방법을 포함

 

Part B

- 차량 대상 완화 방안 설명

- 8개의 카테고리, 24개의 보안 대책 포함

 

Part C

- 차량 외부 인프라 대상 완화 방안 설명

- 3개 카테고리, 9개 보안 대책 포함

 

CSMS, VTA 차량 제조사는 Annex 5 내용을 TARA 시 어떻게 고려했는지 증명해야 함

---

보안 위협 구분

1. 백엔드 서버

2. 통신 채널

3. 업데이트 절차

4. 휴먼 에러

5. 차량 외부 연결

6. 차량 저장 코드/데이터

7. 잠재적 취약점

- 데이터의 물리적 손실은 삭제되어 더 이상 Annex 5에서 다루지 않음

 

보안 위협 이해를 위한 두가지 관점

위협 발생 위치

- 실제 위협이 발생한 위치를 기준으로 분류

- 차량 내부, 차량 외부

 

관리 영역

- 정보보호 관리 영역 기준 구분

- 관리적 위협, 기술적 위협, 물리적 위협

---

백엔드 서버

1. 백엔드 서버를 통한 차량 공격 or 백엔드 서버로부터 데이터 유출

- 내부자 공격: 직원의 권한 남용 (관리)

- 인터넷을 통한 비인가 서버 접근 (기술)

- 물리적으로 비인가 서버 접근 (물리)

 

2. 백엔드 서버의 서비스 중단

- 차량-백엔드 서버 간 상호작용에 의존적인 서비스의 통신 방해, 결국 이를 통한 특정 서비스 제공 방해 (기술)

 

3. 백엔드 서버에 저장된 차량 관련 데이터 손실/유출

- 내부자 공격: 직원의 권한 남용 (관리)

- 클라우드에서 정보 유출 (기술)

- 인터넷을 통한 비인가 서버 접근 (기술)

- 물리적으로 비인가 서버 접근 (물리)

- 의도하지 않은 데이터 공유로 인한 정보 유출 (관리, 기술)

---

통신 채널

4. 차량이 수신하는 메시지/데이터 스푸핑

- 가장(impersonation)을 통한 메시지 스푸핑 (기술)

- 시빌(Sybil) 공격 (도로 상 차량이 많은 것처럼 다른 차량을 속이는 공격) (기술)

 

5. 차량 내 코드 / 데이터에 대한 비인가된 조작/삭제

- 코드 주입 (기술)

- 통신 채널을 통한 차량 내 저장 데이터 조작/덮어쓰기/삭제 (기술)

- 통신 채널을 통한 차량 내 신규 데이터 쓰기 (기술)

 

6. 신뢰되지 않은 출처로부터 메시지 수용 + 세션 하이재킹, 재전송

- 신뢰되지 않은 출처로부터의 정보 수신 (기술)

- 중간자 공격, 세션 하이재킹 (기술)

- 재전송 공격 (기술)

 

7. 정보 공개

- 정보 유출, 통신 방해, 통신 모니터링 (기술)

- 민감한 파일/데이터에 대한 비인가된 접근 (기술)

 

8. 서비스 거부 공격으로 차량 기능 방해

- 차량으로 대량의 쓰레기 데이터 전송 (기술)

- 블랙홀 공격 (차량 간 통신 방해 목적으로 차량 간 송수신되는 메시지를 모두 차단) (기술)

 

9. 권한 상승/우회

- 권한 없는 사용자 특정 권한에 접근 (기술)

 

10. 바이러스 감염

- 통신 매체에 포함된 바이러스가 차량 시스템을 감염 (기술)

 

11. 차량이 수신한 메시지에 포함된 악성 콘텐츠

- 악성 차량 내부 메시지 (기술)

- 악성 V2X 메시지 (기술)

- 악성 진단 메시지 (기술)

- 악성 OEM/Supplier가 자체 정의한 메시지

---

업데이트 절차

12. 업데이트 절차의 오용 및 손상

- OTA 업데이트 절차 손상 (기술)

- (유선) 업데이트 절차 손상 (기술)

- 소프트웨어가 업데이트 이전에 손상 (업데이트 절차는 정상) (기술)

- 소프트웨어 공급자의 암호 키 손상으로 인한 잘못된 업데이트 허용 (기술)

 

13. 정상적인 업데이트 방해

- 업데이트 서버나 네트워크에 대한 서비스 거부 공격, 이를 통해 업데이트 배포, 고객 요청에 따른 기능 잠금 해제 방해 (기술)

---

휴먼 에러(실수)

* 14번은 삭제됨. 사이버보안 위협 방주를 벗어남

 

15. 인가된 사람에 의한 의도치 않은 사이버보안 공격 야기

- 의도하지 않게 악성코드 실행 또는 공격 활성화 유도 (관리 )

- 정의된 보안 절차 미준수 (관리)

---

차량 외부 연결

16. 차량 커넥티비티 기능 (무선) 조작

- 원격에서 차량을 조작할 수 있는 기능의 조작 (기술)

- 차량 텔레메틱스 조작 (기술)

- 통신 간섭: 단거리 무선 통신 시스템 or 센서 (기술)

 

17. 서드 파티 소프트웨어

- 차량 시스템 공격 수단으로 사용되는 손상된 SW 또는 보안이 취약한 SW. 서드 파티에서 작성되어 OEM/Supplier에 제공되는 소프트웨어 (관리, 기술)

 

18. 외부 인터페이스(유선)을 통한 공격

- 코드 인젝션의 공격 포인트로 이용되는 외부 인터페이스 (USB등) (기술)

- 바이러스에 감염된 미디어를 차량 시스템에 연결 (기술)

- 진단 포트를 통한 차량 접근 (차량 매개변수 조작) (기술)

---

차량 저장 코드/데이터

19. 차량 데이터 추출

- 차량 시스템에서 저작권/고유 재산권을 가진 소프트웨어 추출 (기술)

- 소유자 개인정보에 대한 비인가된 접근 (기술)

- 암호 키 추출 (기술)

 

20. 차량 데이터 조작

- 불법적/비인가된 차량 전자 ID 변경 (기술)

- 신원 사기 (기술)

- 모니터링 시스템 회피를 위한 행동 (기술)

- 차량 주행 데이터(마일리지, 주행속도/방향 등) 변조를 위한 데이터 조작 (기술)

 

21. 차량 데이터 삭제

- 시스템 이벤트 로그의 비인가된 삭제/변조 (기술)

 

22. 악성코드 설치

- 시스템에 악성코드 설치 (기술)

 

23. 신규 소프트웨어 설치 or 기존 소프트웨어 덮어쓰기 (기술)

- 차량 제어/정보 시스템 소프트웨어 위조 (기술)

 

24. 시스템 중단/차량 운행 방해

- 캔 버스 플러딩, 시스템에 대한 대량 메시지 송신으로 오류 유발 (기술)

 

25. 차량 파라미터 변조

- 설정 매개변수에 대한 비인가된 접근 및 변조 (기술)

- 충전 매개변수에 대한 비인가된 접근 및 변조 (기술)

---

잠재적 취약점

26. 충분하지 않은 보안 기술의 적용

- 짧은 암호화 키 사용 및 오랜 기간 해당 암호화 키 사용 (관리, 기술)

- 취약한 암호 알고리즘 사용 (관리, 기술)

- 더 이상 사용하지 않거나 곧 그렇게 될 암호 알고리즘 사용 (관리, 기술)

 

27. 충분하지 않은 보안 기술의 적용

- 보안 위협에 취약하도록 설계가 되었거나 위협을 완화할만한 보안 설계가 없는 HW 또는 SW (관리)

 

28. SW, HW 개발 과정에서의 취약점

- 소프트웨어 버그 (관리, 기술)

- 개발 과정에서 사용된 잔재의 사용 (관리, 기술)

 

29. 취약한 네트워크 디자인

- 불필요하게 열려있는 인터넷 포트를 통해 네트워크 시스템에 대한 접근 (관리, 기술)

- 네트워크 분리 우회를 통해 다른 도메인에 접근하여 임의의 CAN bus 메시지 전송 (관리, 기술)

 

* 30번 삭제. 사이버보안 범주 벗어남

 

31. 의도하지 않은 데이터 전송

- 정보 유출: 차량 판매 등으로 인한 개인 정보 유출 (관리, 기술)

 

32. 시스템에 대한 물리적 조작

- 차량에 승인되지 않은 ECU, 공격장치를 부착하여 중간자 공격을 수행. 승인된 하드웨어를 승인되지 않은 하드웨어로 교체. 센서에 의해 수집된 정보 조작. (관리, 기술)

---

Part B. 완화 방안: 차량

상위 수준의 완화방안 제시. 7개 카테고리, 총 19개

통신 채널, 업데이트 절차, 휴먼 에러, 차량 외부 연결, 차량 저장 코드/데이터, 잠재적 취약점, 차량에서의 데이터 유출에 대한 대응 방안을 테이블로 제공

 

Part C. 완화 방안: 차량 외부 인프라

상위 수준의 완화방안 제시. 3개 카테고리, 총 9개

백엔드 서버, 휴먼 오류, 물리적 데이터 손실 (part A에선 삭제되었는데 Mitigation에선 삭제 안된 상태)

---

보안 솔루션

보안 솔루션의 종류/구현 메커니즘은 차량 제조사, 차종마다 각기 다르게 적용 가능

최소한 적용되는 일반적인 보안 솔루션 설명

보안 솔루션	설명
Secure boot	제어기 SW(부트로더 포함)의 무결성을 검증하기 위한 기술
Secure flash	제어기 펌웨어 리프로그래밍 시 수신한 펌웨어의 무결성 및 진본성을 검증하는 보안 기술
Secure debug	제어기가 가진 디버그 인터페이스로의 접근을 통제하기 위한 기술
Secure access	제어기 진단통신 시 접근 제어를 위한 기술
Secure communication	제어기 간 (또는 차량 외부 구성 요소와) 통신 시 기밀성, 무결성, 진본성 등을 제공하기 위한 보안 기술
CAN-IDS, VSOC	차량 내부 네트워크에서 이상 탐지를 위한 보안 기술. 백엔드에서 상세 분석을 위한 보안 인프라

 

Secure Boot

목적

- 제어기 부팅 시 SW(부트로더 포함)의 무결성을 검증하기 위한 보안 기술

- 공격자가 변조된 펌웨어를 제어기에 설치 시 공격자의 의도대로 차량 제어 가능

- 따라서 제어기에서는 차량 제조사가 승인한 소프트웨어 이외엔 실행되지 않도록 해당 기술 사용

 

메커니즘

1. 의도한 SW의 MAC 값 사전 생성

2. 제어기 부팅 시마다 해당 SW와 사전에 생성해둔 MAC 비교

3.1. 값이 동일한 경우 -> 부팅 허용

3.2. 값이 동일하지 않은 경우 -> 부팅 차단 또는 기능 제한

 

전제 조건

- HSM과 같이 안전하게 MAC 값을 저장하기 위한 저장소 필요

 

BOOT_MAC

- 차량 제조사가 의도한 소프트웨어임을 확인하기 위한 값

- 대칭키 기반 메시지 인증 코드

 

BOOT_MAC_KEY

- 인증값을 생성하기 위한 키

- 제어기의 HSM 내부 저장소에 저장됨

 

Secure Flash

목적

- 제어기 펌웨어 리프로그래밍 시 수신한 펌웨어의 무결성 및 진본성을 검증하는 보안 기술

- 악성/변조된 소프트웨어 설치 방지

- 소프트웨어 업데이트 시 정당한 소프트웨어인지 암호학적 방법을 통한 검증 수행

- 가장 널리 사용되는 암호학적 검증 방법: 공개키 기반의 전자 서명 & 서명 검증

- 차량 제조사에 따라 소프트웨어 업데이트 패키지 자체에 대한 기밀성을 보장하기도 함

 

메커니즘

1. 소프트웨어 업데이트 패키지에 차량 제조사 개인키로 전자 서명

2. 제어기에서 차량 제조사의 공개키로 전자서명 검증

3.1. 전자서명 성공 -> 소프트웨어를 제어기 메모리에 write 수행

3.2. 전자서명 실패 -> 소프트웨어 업데이트 절차 중단

 

전제 조건

- HSM과 같이 안전하게 차량 제조사 공개키 값을 저장하기 위한 저장소 필요

- 공개키인데 왜?

    - 공개키의 위변조 방지. 신뢰 체계 유지 (신뢰 체계의 시작점이 되는 키는 변조되면 안됨)

 

전자서명 값 생성

- 전자 서명은 차량 제조사에서만 가능함

    - 차량 제조사에 의해 승인되는 거니 개인키를 쓰는데 차량 제조사만 앎.

1. 협력사는 차량 제조사로 전자 서명을 요청 (SW 포함)

2. 차량 제조사는 SW에 대한 전자서명 값 생성

3. 협력사에 전자서명 값, 차량 제조사의 공개키 회신

4. 협력사는 SW, 전자서명값, 차량제조사의 공개키를 제어기에 주입하여 납품

 

전자서명 값 검증

- 전자 검증은 소프트웨어 업데이트 시 제어기에서 이루어짐

1. 수신한 업데이트 패키지에서 전자서명 분리

2. 전자 서명 값 검증

    - 사전에 HSM에 주입된 차량 제조사 공개키 이용

    - 차량 제조사 기준에 맞는 알고리즘을 사용하여 전자 서명 검증 수행

3.1. 전자서명 검증 성공

    - SW를 제어기 메모리에 write

    - Secure boot를 위한 MAC 값 생성 및 HSM 내 슬롯에 저장

3.2. 전자서명 검증 실패

    - 업데이트 실패 통보

 

 

Secure debug

목적

- 제어기가 가진 디버그 인터페이스로의 접근을 통제하기 위한 기술

- 양산 시 디버깅이 가능한 모든 외부 인터페이스를 영구적으로 제거가 필요하지만 물리적인 제거가 어려운 경우 인증 등의 접근 제어 메커니즘 적용이 필수적

 

메커니즘

1. 디버그 인터페이스를 통한 접근 시 HSM을 이용한 인증 또는 사전 정의된 PW기반 인증 요청

2. 인증 성공 시에만 디버그 인터페이스 접근 가능

 

전제 조건

- HSM 적용 또는 MCU(Micro Controller)수준의 접근제어 메커니즘 제공

 

패스워드 기반 접근 제어

- MCU 제조사에서 해당 기능을 제공함에 따라 패스워드 길이, 복잡도 등 제공 가능

- MCU 칩 선정 단계에서부터 사이버보안에 대한 고려가 필수적

 

방법1. 사전 정의된 패스워드 기반 인증 방식

- MCU 제조사와의 가이드, 협의에 따라 패스워드 설정 (1회성. 패스워드 변경 불가)

- MCU 하나일 때 가능

 

방법2. HSM을 이용한 인증 방식

- Input: MCU별 각각 다른 PW를 제공하기 위한 인자값

- 키 유도함수를 통해 유도한 키를 디버그 인터펫=이스 접근 패스워드로 사용

 

 

Secure access

목적

제어기 진단 통신 시 접근 제어를 위한 기술

OBD2 장착 의무화 시행에 따라 각 ECU는 이를 통해 진단 통신이 가능

- 공격자가 진당 통신을 통해 제어기에 접근하여 악의적 행위를 하는 것을 통제할 필요가 있음

 

진단 통신을 통해 수행할 수 있는 기능들

- 통신 관리, 데이터 RW, 저장 데이터 RW, IO 제어, 리프로그래밍

 

메커니즘

- 정비진단기 <-> 제어기 통신 간 상호 합의된 계산 절차를 통해 도출된 값을 확인하는 방식으로 상대방 확인

- 매 통신 시마다 각기 다른 도출값을 위해 난수를 이용

- 상기 절차: ISO 14299, Seed & Key 알고리즘

- 난수 생성을 위해 HSM 사용

 

전제조건

- HSM

 

난수 기반 Seed & Key 알고리즘

1. 정비 진단기: Seed 생성 요청

2. 제어기: Seed 생성, 반환

3. 제어기: 생성한 Seed 기반으로 정비 진단기와 동일한 키 생성 알고리즘으로 키 계산

4. 정비 진단기: 수신한 Seed 기반으로 키 생성 알고리즘으로 키 계산, 제어기로 전송

5. 제어기: 정비 진단기로부터 수신한 키와 생성한 키가 동일한지 확인하여 인증을 완료

6.1. 키가 동일한 경우 접근 허용

6.2. 키가 동일하지 않은 경우 접근 차단

 

 

Secure Communication

목적

- 제어기 간 통신 시 기밀성, 무결성, 진본성 등을 제공하기 위한 보안 기술

 

메커니즘

- 전송 데이터(페이로드)에 대한 Integrity, Freshness 보장을 위한 값 추가하여 전송

- Integrity -> 비밀키를 이용한 MAC 생성

- Freshness -> MAC 생성 시 인자로 시간 또는 카운터 값 추가

 

전제 조건

- 통신 개체 간 시간 또는 카운터 동기화 및 동일한 알고리즘 합의

- HSM

 

AUTOSAR SecOC

- 4.3 이후부터 사용 가능

- 보안온보드 통신 (SecOC)
- CAN은 데이터 페이로드가 8바이트밖에 안됨. 이더넷이나 CAN-FD에서 유용하게 사용됨

 

 

CAN-IDS and VSOC

목적

- 차량 내부 네트워크 - CAN 통신 시 이상 탐지하기 위한 보안 기능

- 네트워크 기반 IDS가 일반적. 차량 내부 네트워크에서 모든 데이터를 취급하는 제어기에 해당 기능을 탑재

- CAN IDS: 차량 내부에 탑재되어 이상행위 탐지 후 백엔드 인프라에 전송

- VSOC: 백엔드 인프라. 차량에서 탐지된 로그를 수신하여 분석 후 이상 여부 판단

 

메커니즘

- CAN-IDS: 사전 정의된 룰에 의거한 이상 탐지 후 VSOC에 보고

- VSOC(Vehicle Security Operations Center): 차량들로부터 수신된 자료 분석 및 대응 방법 모든 차량에 배포

 

동작 흐름

1. 탐지

2. 보고

3. 분석

4. 대응책 개발

5. 전 차종에 배포

 

---

 

ITU-T SG17 Q13

ITU-T

- International Telecommunication Union-Telecomunication Standardization Center

- 국제 전기통신연합 전기통신표준화 부문

 

SG17 (Study Group 1y)

- ITU-T 산하 정보보호 분야 표준을 개발하는 연구반

 

Q13

- 지능형 교통 체계 (ITS, Intelligent Transport Systems) Security 주제 담당

 

국제 표준화 단계

신규 제안(NWIP) -> 표준 개발 (1 ~ 2년) -> 사전 채택 -> 국제 회람 (3 ~ 4개월) -> 최종 승인