전자서명은 어떻게 동작하는가 — Secure Boot·OTA의 핵심 원리

차량 보안 기초 — 암호학 시리즈

암호학 시리즈 전체 구성

1

이전 글

암호학이란 무엇인가 — 단방향과 양방향

Hash · 무결성 · 기밀성 · 암호학 전체 구조

DONE

2

이전 글

대칭키 vs 비대칭키 — 차량에서 왜 둘 다 쓸까

AES · RSA · ECC · 키 배포 문제 · 차량 적용

DONE

3

3편 · 지금 읽는 글 · 시리즈 완결

전자서명은 어떻게 동작하는가 — Secure Boot·OTA의 핵심

전자서명 · 인증서 · Chain of Trust · Secure Boot · OTA

NOW

지금까지 배운 것

1편: Hash(단방향) = 변조 확인 / Encryption(양방향) = 기밀성 보호
2편: 대칭키 = 빠르지만 키 배포 문제 / 비대칭키 = 키 배포 해결, 공개키·개인키 쌍
3편에서: 이 두 개가 결합되어 전자서명이 됩니다. 그리고 Secure Boot와 OTA가 이것 위에서 동작합니다.

2편이 끝날 때 이런 질문을 남겼습니다.

"진짜 OEM이 만든 OTA"라는 걸 차량은 어떻게 확인할 수 있을까?

암호화만으로는 안 됩니다. 데이터를 숨기는 건 할 수 있어도, "누가 만들었는가"를 증명하지는 못합니다.

전자서명(Digital Signature)은
1편의 Hash와 2편의 비대칭키가 결합된 기술입니다.

"이 파일이 원본 그대로이며,
신뢰할 수 있는 주체가 만들었다"는 것을 증명합니다.

---

전자서명 = Hash + 비대칭키

전자서명의 구조는 단순합니다. 1편과 2편에서 배운 두 개념을 조합합니다.

전자서명 = 두 개념의 결합

Hash
(1편 — 무결성)

+

비대칭키
(2편 — 개인키)

=

전자서명
(무결성 + 인증)

Hash만으로는 "변조 여부"는 확인할 수 있지만 "누가 만들었는지"는 알 수 없습니다. 비대칭키를 더함으로써 "이 Hash는 개인키를 가진 주체만 만들 수 있다"는 걸 증명합니다.

---

전자서명 — 만드는 과정 (서명 생성)

OEM이 Firmware에 서명을 만드는 과정입니다.

🔏 서명 생성 — OEM 측

Firmware
원본

→

SHA-256
Hash 계산

→

OEM
개인키 서명

→

전자서명
생성

Firmware 전체가 아닌 Hash 값에 서명 — 연산 효율 + 보안성

Firmware 전체에 직접 서명하지 않고 Hash 값에 서명하는 이유가 있습니다. Firmware는 수십 MB가 될 수 있지만 Hash 값은 항상 고정 길이(256비트)입니다. 연산이 훨씬 효율적이고, 조금이라도 변조되면 Hash가 달라져 감지됩니다.

---

전자서명 — 확인하는 과정 (서명 검증)

차량 ECU가 Firmware를 받았을 때 검증하는 과정입니다.

✅ 서명 검증 — ECU 측

받은
Firmware

→

Hash
재계산

→

OEM
공개키로 검증

→

Hash
일치 여부

공개키는 ECU 내부(HSM)에 미리 저장 — 누구나 볼 수 있어도 안전

검증 로직:
공개키로 서명을 풀면 OEM이 만든 Hash 값이 나옵니다. 직접 계산한 Hash와 이 값이 같으면 — 원본 그대로이고 OEM이 서명한 파일입니다. 다르면 — 변조되었거나 가짜 서명입니다.

---

변조가 생기면 어떻게 되나

✅ 정상 시나리오 — 원본 Firmware

1. ECU가 Firmware Hash 계산 → A1B2C3...
2. 공개키로 서명 검증 → A1B2C3...
3. 두 값 일치

→ 서명 검증 성공 · 부팅 계속

⚠️ 공격 시나리오 — 변조된 Firmware

1. 공격자가 Firmware에 악성 코드 삽입
2. ECU가 Hash 계산 → FF9911... (완전히 다른 값)
3. 공개키로 서명 검증 → A1B2C3... (원본 Hash)
4. 두 값 불일치

→ 서명 검증 실패 · 부팅 중단 · OTA 거부

중요한 포인트: 전자서명은 "변조를 막는 기술"이 아닙니다. "변조를 감지하는 기술"입니다. 공격자가 파일을 바꿀 수는 있지만, OEM의 개인키 없이는 새로운 서명을 만들 수 없습니다.

---

Secure Boot — 신뢰 체인(Chain of Trust)

Secure Boot는 전자서명을 부팅 과정 전체에 적용한 구조입니다. ECU가 켜지는 순간부터 Application이 실행되기까지 모든 단계에서 서명을 검증합니다.

CHAIN OF TRUST — Secure Boot 구조

🔒

ROM Bootloader (신뢰 앵커)

칩 제조 시 하드웨어에 고정 — 변경 불가, 최초 신뢰의 출발점

변경 불가

📋

1차 Bootloader 서명 검증

ROM이 공개키로 1차 Bootloader 서명 검증 → 정상이면 실행

전자서명

⚙️

OS / Kernel 서명 검증

1차 Bootloader가 OS 서명 검증 → 정상이면 실행

전자서명

📱

Application 서명 검증

OS가 Application 서명 검증 → 정상이면 실행

전자서명

✅ Chain of Trust 핵심:
"신뢰할 수 있는 출발점(ROM)"에서 시작해서 각 단계가 다음 단계를 검증합니다. 체인 어느 곳에서든 검증 실패하면 부팅이 중단됩니다. 공격자는 체인 전체를 뚫지 않으면 악성 코드를 실행시킬 수 없습니다.

---

인증서 — "이 공개키는 진짜 OEM 것인가"

여기서 또 하나의 질문이 생깁니다. ECU 안에 저장된 공개키가 진짜 OEM 것인지 어떻게 알 수 있을까요?

이 문제를 해결하는 게 인증서(Certificate)입니다.

X.509 인증서 주요 구성요소

Subject

이 인증서가 누구 것인지 — "OEM A의 코드서명 키"

Public Key

인증서 주체의 공개키 — 검증에 사용할 키

Issuer

이 인증서를 발급한 기관 — CA(Certificate Authority)

Validity

유효 기간 — 만료된 인증서는 신뢰하지 않음

CA Signature

발급 기관의 전자서명 — 이 인증서 자체가 위조되지 않았음을 보증

인증서 = "공개키의 신분증"입니다.
신분증처럼 "이 공개키는 OEM A 것이며, 신뢰할 수 있는 기관(CA)이 보증한다"는 내용이 담겨 있습니다.

PKI — 인증서 신뢰 계층 구조

인증서는 계층 구조로 신뢰를 전달합니다.

PKI 인증서 계층 구조

ROOT CA

루트 인증 기관 — 최상위 신뢰 앵커. 자기 자신을 서명

↓ 서명

Intermediate CA

중간 인증 기관 — Root CA가 신뢰 보증. OEM이 운영하는 경우 많음

↓ 서명

Leaf Certificate

실제 사용 인증서 — ECU 코드서명, OTA 서명 등에 사용

Secure Boot와 OTA는 이 계층 구조에서 Leaf 인증서를 사용합니다. ECU는 Root CA의 공개키만 가지고 있어도 체인을 따라 Leaf 인증서까지 검증할 수 있습니다.

---

그래서 HSM이 중요하다

전자서명에서 가장 중요한 건 개인키(Private Key) 보호입니다. 개인키가 유출되면 공격자도 "정상 서명"을 만들 수 있게 됩니다. Secure Boot 전체가 무너집니다.

HSM이 전자서명에서 담당하는 역할

개인키 저장

개인키를 외부에서 읽을 수 없는 영역에 보관. Firmware Dump로 추출 불가

서명 연산 내부 처리

서명 생성·검증 연산이 HSM 내부에서만 수행. 키 값이 외부에 노출 안 됨

공개키 저장

검증에 쓰는 OEM 공개키를 안전하게 보관. 변조 시도 감지 가능

Anti-Tamper

물리적 공격 감지 시 키 자동 삭제. 하드웨어 수준 보호

⚠️ 전자서명 보안 수준은 결국 개인키를 얼마나 안전하게 보호하느냐에 달려 있습니다.

키가 유출되면 공격자가 가짜 Firmware에도 "정상 서명"을 붙일 수 있습니다. Secure Boot가 있어도 뚫립니다.

---

현업에서는 이렇게 느낀다

현업 경험 4가지

Secure Boot는 단순 보안 기능이 아니라 신뢰 체계 전체다 — ROM부터 Application까지 연결된 Chain of Trust가 깨지면 어느 한 지점에서 뚫립니다. 체인 설계가 중요합니다.

개인키 관리가 전체 보안의 핵심이다 — 암호화 알고리즘이 아무리 강해도 개인키가 유출되면 의미가 없습니다. 키 생성·저장·폐기 프로세스가 별도로 필요합니다.

OTA와 Secure Boot는 결국 같은 구조 위에 있다 — 전자서명·인증서·공개키 검증. 이 구조를 이해하면 두 기술이 어떻게 연결되는지 보입니다.

인증서 만료·폐기 관리가 생각보다 복잡하다 — 차량이 수년간 운영되면서 인증서가 만료되면 어떻게 할 것인가. OTA로 갱신 가능한지, PKI 체계는 어떻게 운영할 것인지가 실제 프로젝트에서 논의됩니다.

---

3편을 마치며 — 시리즈 전체 연결

암호학 시리즈 핵심 흐름 정리

1

Hash(단방향) — 데이터가 변조됐는지 확인. 복호화 불가. SHA-256이 대표

2

대칭키 — 빠른 데이터 암호화. 키 배포 문제 존재. AES가 대표

3

비대칭키 — 공개키/개인키 쌍. 키 배포 문제 해결. ECC·RSA가 대표

4

전자서명 = Hash + 비대칭키. 무결성 + 인증을 동시에 증명

5

Secure Boot = 전자서명을 부팅 전 과정에 적용한 Chain of Trust

---

마무리

차량 보안 기술 대부분은 결국 세 가지 위에 서 있습니다.

Hash로 변조를 감지하고,
비대칭키로 신뢰를 만들고,
전자서명으로 "누가 만든 것인가"를 증명합니다.

그리고 그 신뢰 구조가 Secure Boot와 OTA의 핵심입니다.

이제 Secure Boot, OTA 무결성 검증, SecOC, HSM, Certificate 이야기를 만날 때 — 그 안에서 Hash와 비대칭키와 전자서명이 어떻게 맞물려 동작하는지 보일 겁니다.

핵심 요약

1

전자서명 = Hash + 비대칭키 — 무결성(Hash)과 인증(개인키)을 동시에 증명합니다

2

서명 생성은 개인키, 검증은 공개키 — 개인키 없이는 서명 위조 불가능합니다

3

Secure Boot = Chain of Trust — ROM부터 Application까지 모든 단계에서 서명 검증합니다

4

인증서 = 공개키의 신분증 — PKI 계층 구조로 "이 공개키는 신뢰할 수 있다"를 보증합니다

5

전체 보안 수준은 개인키 보호에 달려있다 — HSM이 중요한 이유입니다

전자서명 SecureBoot ChainOfTrust OTA보안 인증서 PKI HSM 차량사이버보안 암호학기초 ECC