J1939-91C란 무엇일까? — 상용차 CAN 통신 보안은 SecOC와 무엇이 다를까?

차량 보안기술 — 통신 보안

차량 통신 보안 시리즈

1

이전 글

자동차 메시지는 어떻게 신뢰할 수 있을까?

SecOC 쉽게 이해하기 — MAC과 Freshness Value

DONE

2

지금 읽는 글

J1939-91C란 무엇일까?

상용차 CAN 통신 보안은 SecOC와 무엇이 다를까

NOW

J1939 보안에 대해 자주 듣는 말

"J1939-91C가 SecOC랑 비슷한 거 아닌가요? 그냥 상용차용 SecOC 아닌가요?"

"상용차도 AUTOSAR 쓰면 SecOC 적용하면 되는 거 아닌가요?"

"PKI가 자동차에 왜 필요하죠? 서버도 아닌데요."

"CAN FD가 일반 CAN이랑 어떻게 다른지 잘 모르겠어요."

자동차 사이버보안을 공부하다 보면 SecOC를 자연스럽게 접하게 된다. 그런데 상용차 영역에서는 조금 다른 이름이 등장한다 — SAE J1939-91C.

둘 다 CAN 메시지 위변조를 막기 위해 만들어졌다. 하지만 접근 방식이 다르다. SecOC가 메시지의 신뢰를 만든다면, J1939-91C는 네트워크 자체의 신뢰를 만든다.

---

먼저 — J1939가 무엇인가

SecOC는 AUTOSAR 플랫폼 위에서 동작하는 승용차 중심 기술이다. 상용차 세계는 다른 기반 위에 서 있다. SAE J1939다.

J1939는 SAE(미국 자동차공학회)가 정의한 상용차용 CAN 통신 표준이다. 트럭, 버스, 건설장비, 농기계, 특장차에서 오랫동안 사용해 온 업계 공통 언어다. CAN 프로토콜 위에서 동작하며, PGN(Parameter Group Number)이라는 표준화된 메시지 식별 체계를 사용한다.

ℹ️ J1939와 AUTOSAR의 위치

승용차가 AUTOSAR 소프트웨어 아키텍처를 중심으로 발전해왔다면, 상용차는 J1939를 공통 언어로 삼아 독자적인 생태계를 구축해왔다. 같은 CAN을 쓰지만 위에 올라가는 프로토콜 스택과 메시지 구조가 근본적으로 다르다.

---

J1939도 같은 문제를 가지고 있었다

J1939 역시 CAN 기반이다. 그렇다면 SecOC 편에서 다룬 것과 같은 문제가 그대로 존재한다. 메시지에 기본적인 송신자 인증이 없다. 공격자가 같은 PGN으로 가짜 메시지를 주입하면 수신 ECU가 구분하기 어렵다.

⚠️ 상용차에서 위협이 더 심각한 이유

승용차 한 대가 잘못된 제어를 받으면 탑승자가 위험해진다. 상용차는 차원이 다르다. 대형 트럭의 브레이크 메시지가 위조되면 수십 톤의 차량이 제어를 잃는다. 버스의 조향 메시지가 조작되면 수십 명의 승객이 위험에 처한다. 게다가 상용차는 운행 기간이 길고 차량 한 대의 경제적 가치가 크다. 그리고 OTA, 원격 진단, Fleet Management로 외부 연결이 빠르게 확대되고 있다.

---

J1939-91C — 메시지 보호를 넘어 네트워크 신뢰로

J1939-91C는 CAN FD 네트워크에서 메시지 인증·무결성·기밀성을 확보하기 위한 SAE 표준이다. 한 가지 중요한 사실을 먼저 짚고 가자.

💡 J1939-91C는 현재 Draft 단계다. 아직 최종 확정된 표준이 아니다. 구현 사례와 검증 논문은 존재하지만, 세부 스펙은 추후 변경될 수 있다. 이 글은 공개된 SAE 기술 논문과 구현 사례를 기반으로 작성됐다.

❌ J1939-91C는 상용차용 SecOC다 — 같은 방식으로 메시지에 MAC을 붙이는 기술이다

✅ J1939-91C는 네트워크 참여 자격을 먼저 확인하고, 네트워크 전체가 공유하는 키를 기반으로 메시지를 보호한다

SecOC는 개별 ECU 쌍이 미리 공유된 키로 메시지를 보호한다. J1939-91C는 Leader ECU가 네트워크를 구성하고 Follower ECU들의 참여를 검증한 뒤, 네트워크 공유 키를 배포해 보안 통신을 시작한다. 개별 메시지 보호보다 네트워크 신뢰 구조 수립이 먼저다.

SecOC vs J1939-91C — 보안 통신 시작 방식 비교

SecOC
사전 공유키
전제

→

메시지
+ CMAC
전송

→

수신 ECU
CMAC 검증

SecOC: 키가 이미 있다는 것을 전제. 메시지 레벨 보호.

J1939-91C
Network
Formation

→

키 배포
(Rekey)

→

보안 메시지
+ CMAC
+ Freshness

→

수신 ECU
검증

J1939-91C: 네트워크 신뢰 구조를 먼저 수립하고 그 위에서 메시지를 보호한다.

---

J1939-91C의 세 가지 핵심 단계

J1939-91C의 동작은 세 단계로 구성된다. SAE 기술 논문과 구현 사례에서 공통적으로 확인되는 구조다.

J1939-91C 세 가지 핵심 단계

1

Network Formation (네트워크 구성) — 네트워크에는 Leader ECU가 하나 있고 나머지는 Follower로 참여한다. Follower는 네트워크 참여 시 고유한 검증 시퀀스를 통해 정당한 노드임을 확인받아야 한다. 검증에 실패한 ECU는 네트워크에 참여할 수 없다. 특정 ECU가 비정상 메시지를 전송하면 해당 ECU만 격리하고 나머지 네트워크는 정상 운영을 유지할 수 있다.

2

Rekey (키 갱신) — 세션 키는 영구적이지 않다. Leader ECU가 주기적으로 Rekey를 트리거하면 모든 Follower가 새 키를 동기화한다. Freshness Counter가 롤오버될 시점이나 보안 정책에 따라 갱신 주기를 조정한다. 키를 주기적으로 교체함으로써 키 유출 시 영향 범위를 시간 단위로 제한한다.

3

Secure Messaging (보안 메시지 전송) — 네트워크가 구성되고 키가 배포되면 각 메시지는 Assurance Header를 포함한다. Assurance Header에는 Freshness Value와 CMAC(Cipher-based MAC) 필드가 포함된다. 수신 ECU는 CMAC으로 메시지 인증과 무결성을 확인하고, Freshness Value로 Replay Attack을 방어한다. 선택적으로 메시지 payload를 암호화할 수도 있다.

ℹ️ PKI와 인증서는 어디서 등장하는가?

J1939-91C 관련 문서에서 PKI와 디지털 인증서가 언급되는 것은 맞다. Network Formation 단계에서 ECU의 신원을 확인하는 메커니즘으로 PKI 기반 인증서가 활용될 수 있다. 다만 J1939-91C 자체가 PKI를 필수로 규정하기보다는, ECU 신뢰 확인을 위한 방법 중 하나로 활용 가능한 구조다. 표준이 아직 Draft 단계라 이 부분의 세부 스펙은 최종 확정 전에 변경될 수 있다.

---

왜 CAN FD가 전제인가

J1939-91C가 기존 CAN이 아니라 CAN FD를 전제로 설계된 것은 실용적인 이유가 있다.

구분	CAN (Classic)	CAN FD
최대 Payload	8 Byte	64 Byte
최대 속도	1 Mbps	8 Mbps (데이터 구간)
보안 정보 전송	MAC을 잘라서 써야 함	Assurance Header(CMAC+Freshness) 전송 가능
SecOC 적용	Truncated MAC 전략 필요	더 긴 MAC 사용 가능
J1939-91C 적용	Network Formation·Rekey 메시지 전송 어려움	네트워크 구성·키 배포 메시지 전송 가능

Network Formation, Rekey, Secure Messaging 단계에서 교환되는 메시지들은 8바이트 payload에 담기 어렵다. CAN FD의 64바이트 payload가 있어야 이 구조가 실용적으로 동작한다. J1939-91C가 J1939-22(CAN FD 기반 J1939)를 먼저 이해해야 하고, CAN FD를 전제로 하는 이유다.

---

SecOC와 J1939-91C — 무엇이 더 나은가

두 기술은 목적이 다르기 때문에 "어느 것이 더 낫다"는 질문 자체가 잘못된 프레임이다.

SecOC vs J1939-91C — 강점과 약점 비교

SecOC

메시지 보호 중심 / 승용차 주류

✅ 구조 단순, AUTOSAR 통합

✅ 기존 ECU 적용 상대적으로 용이

✅ 계산량 적음, 실시간 성능 유리

⚠️ 사전 공유키 배포 문제 존재

⚠️ 네트워크 참여 ECU 인증 없음

⚠️ 키 유출 시 영향 범위 큼

VS

J1939-91C

네트워크 신뢰 중심 / 상용차 확대 (Draft)

✅ ECU 단위 네트워크 참여 검증

✅ Rekey로 주기적 키 갱신 가능

✅ 키 유출 영향 Rekey 주기 단위로 제한

✅ 선택적 암호화(기밀성) 지원

⚠️ 구조 복잡, 구현 비용 증가

⚠️ CAN FD + J1939-22 전제 필요

⚠️ 아직 Draft — 최종 스펙 변경 가능

💡 핵심 차이를 한 문장으로

SecOC는 "이 메시지가 올바른 키를 가진 ECU에서 왔는가"를 묻는다. J1939-91C는 그 전 단계인 "이 ECU가 네트워크에 참여할 자격이 있는가"를 먼저 묻는다.

---

상용차가 J1939-91C를 선택하는 이유

상용차의 특성이 SecOC보다 J1939-91C 방식을 더 필요하게 만드는 이유가 있다.

상용차 환경의 특수성

1

긴 운행 수명 — 승용차는 평균 10년 내외지만 대형 트럭은 20~30년 운행하는 경우도 있다. 그 기간 동안 ECU가 교체되고 네트워크 구성이 바뀐다. 고정된 사전 공유키 방식보다 동적으로 키를 관리할 수 있는 구조가 유리하다.

2

다양한 제조사 ECU 혼재 — 대형 상용차는 엔진, 변속기, 제동 시스템이 서로 다른 제조사 ECU로 구성되는 경우가 많다. ECU별 인증서를 통해 누가 네트워크에 참여하는지 명확히 확인하는 구조가 공급망 보안 측면에서 유리하다.

3

Fleet Management 연결 확대 — 트럭·버스는 운행 데이터 수집, 원격 진단, OTA 업데이트가 빠르게 확산되고 있다. 외부 연결이 늘어날수록 네트워크 참여 주체를 명확히 인증하는 구조가 더 중요해진다.

---

승용차 vs 상용차 — 왜 각자 다른 길을 걷는가

AUTOSAR와 J1939는 경쟁 관계가 아니다. 서로 다른 산업 생태계의 요구사항을 반영한 결과다.

구분	승용차 (AUTOSAR + SecOC)	상용차 (J1939 + J1939-91C)
기반 플랫폼	AUTOSAR	SAE J1939
보안 기술	SecOC	J1939-91C
보안 접근	메시지 레벨 보호	네트워크 신뢰 + 메시지 보호
키 방식	사전 공유 대칭키	PKI 기반 비대칭키 + 세션 대칭키
ECU 인증	없음 (키 보유 여부로 간접 확인)	인증서 기반 명시적 인증
표준 기관	AUTOSAR 컨소시엄	SAE International

---

🔧 현업에서 느끼는 변화들

상용차 OEM에서 J1939-91C 관심이 빠르게 높아지고 있다 — 불과 몇 년 전까지 상용차 사이버보안은 승용차보다 논의가 많이 늦었다. 그런데 OTA와 Fleet Management 확대로 연결성이 높아지면서 상용차 OEM들의 사이버보안 요구사항이 빠르게 구체화되고 있다. J1939-91C는 이 흐름에서 자주 등장하는 이름이 됐다.

PKI 인프라 구축이 가장 큰 과제다 — J1939-91C의 기술적 개념은 이해하기 어렵지 않다. 어려운 것은 인증서를 발급하고 관리하는 PKI 인프라다. 어떤 CA(인증기관)가 차량용 인증서를 발급하는가, 인증서 유효기간이 만료되면 어떻게 갱신하는가, ECU 교체 시 인증서는 어떻게 처리하는가 — 이런 운영 체계가 기술 구현보다 더 어려운 문제다.

SecOC와 J1939-91C가 한 차량에 공존하는 경우도 생긴다 — 상용차가 SDV화되면서 AUTOSAR 기반 ECU와 J1939 기반 ECU가 한 차량 안에 함께 탑재되는 경우가 늘고 있다. 게이트웨이가 두 세계를 연결해야 하고, 보안 정책이 어떻게 브리징되어야 하는지가 새로운 설계 과제로 등장하고 있다.

SecOC는 메시지에 묻는다 — "이 메시지는 진짜인가?"
J1939-91C는 네트워크에 묻는다 — "이 ECU는 여기 있을 자격이 있는가? 키는 여전히 유효한가?"

두 질문은 서로 다른 층위에서 같은 목표를 향한다. 차량 통신을 신뢰할 수 있게 만드는 것.

핵심 요약

1

J1939-91C는 "상용차용 SecOC"가 아니다 — SecOC는 메시지 보호, J1939-91C는 네트워크 신뢰 구축이 핵심이다. 접근 층위가 다르다.

2

세 단계로 작동한다 — Network Formation(네트워크 참여 검증) → Rekey(주기적 키 갱신) → Secure Messaging(CMAC+Freshness 기반 메시지 보호).

3

CAN FD + J1939-22가 전제다 — Network Formation과 Rekey 메시지를 전송하려면 64바이트 payload의 CAN FD가 필요하다. J1939-22를 먼저 이해해야 한다.

4

상용차의 특수성이 이 방식을 선택하게 만든다 — 긴 운행 수명, 다제조사 ECU 혼재, Fleet 연결 확대가 동적 키 관리와 명시적 ECU 인증을 더 중요하게 만든다.

5

아직 Draft다 — 그래서 지금이 이해할 적기다 — 최종 확정 전이지만 구현 사례가 이미 존재한다. 상용차 사이버보안 흐름을 이해하려면 지금부터 알아둬야 하는 표준이다.

J1939-91C SAE_J1939 SecOC 상용차사이버보안 CAN_FD PKI 차량통신보안 ECU인증 네트워크보안 FleetManagement 차량사이버보안