정비소에서 진단기를 OBD 포트에 꽂으면 고장 코드를 읽고, 부품을 시험 구동하고, ECU 소프트웨어를 새로 쓸 수 있습니다. 진단 기능은 개발과 정비에 꼭 필요한 도구입니다. 그런데 같은 기능이 공격자의 손에 들어가면 어떻게 될까요? 주행거리를 되돌리고, 배출가스 관련 기록을 바꾸고, 주행 중인 차량의 액추에이터를 움직이고, ECU 펌웨어를 통째로 빼낼 수 있습니다. 진단 서비스는 차량에서 가장 강력한 권한이 모이는 곳입니다.
자동차 업계는 오랫동안 UDS(Unified Diagnostic Services, ISO 14229-1)의 Security Access(0x27) 서비스로 이 권한을 잠가 왔습니다. 2020년 개정판에는 인증서를 쓰는 Authentication(0x29) 서비스가 추가되었습니다. 그리고 2026년 6월, EU는 독립 정비업체의 OBD 접근 규칙을 고쳐 제조사가 인증서와 토큰 같은 보안 조치를 쓸 수 있는 조건을 정했습니다. 진단 접근을 어떻게 잠글지는 이제 기술 선택을 넘어 규제의 문제이기도 합니다.
0x27은 무엇이 부족하고, 0x29는 무엇을 해결하며, 0x29를 도입할 때는 무엇에 부딪힐까요? 이 글은 진단 서비스가 왜 공격 표면이 되는지부터 0x27과 0x29의 차이, 도입할 때의 현실 문제, 플래시 프로그래밍 보호까지 차례로 정리합니다.
1. 진단 서비스는 왜 공격 표면이 되는가
진단 클라이언트는 정비소의 외부 진단기일 수도 있고, 다른 ECU의 고장 정보를 모으거나 프로그래밍 세션을 시작하는 차량 내부의 ECU일 수도 있습니다. 진단 요청은 OBD 포트로 들어오기도 하고, 원격 진단 기능을 거쳐 텔레매틱스 단말로 들어오기도 합니다. 어느 경로든 공격자가 진단 클라이언트 행세를 할 수 있다면, 서비스 하나하나가 그대로 공격 도구가 됩니다.
UDS로 할 수 있는 대표적인 공격은 다음과 같습니다.
| 서비스 | 정상 용도 | 악용하면 |
|---|---|---|
| RequestDownload(0x34), TransferData(0x36), RoutineControl(0x31)의 메모리 삭제 | 소프트웨어와 캘리브레이션 재기록 | 악성 코드나 변조한 캘리브레이션 설치 |
| RequestUpload(0x35) | 메모리 내용 읽기 | 펌웨어와 캘리브레이션 추출, 오프라인 취약점 분석 |
| ECUReset(0x11) | ECU 재시작 | 주행 중 재시작으로 기능 상실 |
| WriteDataByIdentifier(0x2E) | 설정값, 식별 정보 기록 | 주행거리 같은 민감한 값의 변조 |
| RoutineControl(0x31)의 시험 루틴 | 액추에이터 시험 구동 | 주행 중 의도하지 않은 구동 |
| 공장용 설정 루틴 | 사양 설정, 암호 키 주입 | 안전하지 않은 설정, 키 바꿔치기 |
여기에 더해 정상 메시지 송신을 멈추게 하는 CommunicationControl(0x28), 고장 코드 기록을 멈추게 하는 ControlDTCSetting(0x85)도 같은 시각으로 봐야 합니다. 앞의 것은 기능을 마비시키는 데, 뒤의 것은 새 고장 기록을 억제해 공격을 알아채기 어렵게 만드는 데 쓰일 수 있습니다. UDS 아래의 전송 계층도 공격 대상입니다. 규격을 어기도록 조작한 메시지로 진단 연결을 끊어 버리는 식입니다.
물론 표의 공격이 실제로 가능한지는 ECU가 각 서비스를 어떻게 구현했는지, 어떤 권한과 차량 상태에서 허용하는지에 달려 있습니다. 이것을 서비스별로 따져 보는 일이 TARA이고, 진단 인터페이스는 TARA의 대표적인 공격 경로입니다. TARA를 실무에서 어떻게 돌리는지는 TARA, 형식적 절차를 넘어 실질적 보안 성과를 만드는 법에서 다뤘습니다.
2. 첫 번째 방어: 쓰지 않는 진단 기능은 없앤다
인증보다 먼저 할 일은 진단 기능의 목록을 만드는 것입니다. UDS 서비스와 루틴뿐 아니라 XCP 같은 캘리브레이션, 플래싱 프로토콜, 그리고 ECU 공급사가 개발과 생산에 쓰려고 넣어 둔 고유 루틴까지 모두 들어가야 합니다. 외부에서 코드를 내려받아 실행하게 해 주는 루틴이 대표적인 예입니다. 인증을 붙인다 해도 양산 차량에 이런 기능이 필요한 이유를 찾기 어렵습니다. 양산 뒤에 필요 없는 기능은 실행할 때 막는 것이 아니라 빌드 설정에서 아예 빼야 합니다.
남겨 두는 기능에는 타당성 검사(plausibility check)를 붙입니다. 액추에이터를 움직이는 시험 루틴은 차량이 정차해 있을 때만 받아들이는 식입니다. 이 검사는 기능안전에서도 요구합니다. 주행 중에 실수로 진단 루틴이 실행되어 위험한 구동이 일어나지 않게 하려는 것이니, 안전과 보안이 같은 장치를 함께 쓰는 사례입니다.
검사는 대상 ECU에만 두지 말고 중앙 게이트웨이에도 둡니다. 진단 요청은 보통 게이트웨이를 거쳐 ECU로 전달됩니다. 차량이 움직이는 동안 게이트웨이가 위험한 요청을 아예 전달하지 않으면, 대상 ECU가 거부하기 전에 안쪽 CAN 망이 악의적인 진단 메시지로 마비되는 일도 막을 수 있습니다.
3. 0x27 Security Access: seed와 key의 구조와 한계
동작 방식
0x27은 진단 서비스를 보안 수준(level)별로 묶어 잠급니다. 예를 들어 한 수준을 풀면 플래시 프로그래밍을, 다른 수준을 풀면 액추에이터 시험 루틴을 쓸 수 있게 설정합니다. 잠금을 푸는 절차는 다음과 같습니다.
- 진단 클라이언트가 seed를 요청합니다(requestSeed, 홀수 번호 하위 기능).
- ECU가 난수 seed를 돌려줍니다.
- 클라이언트는 제조사가 정한 알고리즘으로 seed에서 key를 계산해 보냅니다(sendKey, 짝수 번호 하위 기능).
- ECU는 받은 key가 맞는지 검증하고, 맞으면 그 수준의 서비스를 엽니다.
틀린 key가 여러 번 들어오면 일정 시간 다음 요청을 받지 않도록 지연을 둘 수 있습니다. 0x27이 정하는 것은 이 주고받기 절차까지이고, seed에서 key를 계산하는 알고리즘은 제조사가 정합니다.
제대로 만들면 쓸 만합니다
두 조건을 갖추면 0x27도 효과적인 보호가 될 수 있습니다. seed가 충분히 긴 암호학적 난수일 것, 그리고 key 계산에 NIST나 BSI가 승인한 표준 암호 알고리즘을 충분한 키 길이로 쓸 것입니다. 많이 쓰는 대칭키 방식이라면 seed에 대해 AES 기반 메시지 인증 코드(CMAC)를 계산하는 식입니다.
현장에서 자주 보이는 약점
실제 구현은 이 조건을 지키지 못한 경우가 많았습니다.
- seed가 짧거나 예측할 수 있어, 예전에 관찰한 seed와 key 쌍을 다시 쓰거나 가능한 값을 모두 시도하는 공격이 쉬워지는 경우
- 표준 암호 대신 비트 연산을 섞은 자체 고안 변환식을 쓰는 경우
- 차종이나 플랫폼 전체가 같은 비밀값을 공유해, 한 대에서 알아내면 모두 열리는 경우
- 비밀값이 진단기 소프트웨어 안에 들어 있어, 진단기가 유출되면 비밀도 함께 새는 경우
학계 연구도 이를 뒷받침합니다. Van den Herrewegen과 Garcia는 대형 완성차 4개사의 ECU 펌웨어에서 진단 접근 제어에 쓰이는 암호 3종을 역분석했고, 세 가지 모두에서 실제로 악용할 수 있는 취약점을 찾았습니다. 원인은 자체 설계한 암호 요소와 작은 내부 상태였습니다(ESORICS 2018).
잘 만들어도 남는 구조적 한계
0x27을 표준 암호로 제대로 구현해도 구조에서 오는 한계는 남습니다.
- 권한이 거칩니다. 수준 단위로만 열리므로 “이 정비소에는 이 서비스만”처럼 세밀한 권한을 주기 어렵습니다.
- 비밀 정보를 나눠 줘야 합니다. 널리 쓰이는 대칭키 방식이라면 ECU와 진단기 양쪽에 대응하는 비밀 정보가 있어야 하고, 진단기가 많아질수록 그 비밀을 배포하고 관리하는 부담이 커집니다.
- 0x27만으로는 신원을 증명하지 않습니다. key가 맞았다는 사실을 확인할 뿐, 어떤 업체나 사람이 접근했는지는 0x27 자체로 알 수 없습니다. 이를 추적하려면 진단기나 백엔드 같은 별도 체계가 필요합니다.
- 기한이 없습니다. 한 번 새어 나간 비밀은 바꾸기 전까지 계속 유효하고, 공유 범위가 넓을수록 바꿀 때 영향을 받는 차량과 진단기도 많아집니다.
- 잠금이 풀린 뒤는 확인하지 않습니다. 한 번 열린 뒤에는 같은 연결로 들어오는 요청을 누가 보냈는지 다시 따지지 않습니다.
4. 0x29 Authentication: 인증서로 신원을 확인하고 역할로 권한을 나눈다
0x29는 ISO 14229-1의 2020년판(제3판)에 추가된 서비스로, 0x27 대신 쓸 수 있습니다. 0x29가 제공하는 것은 진단 클라이언트가 누구인지 암호학적으로 확인하는 인증(authentication)입니다. 인증에 성공한 클라이언트에게 어떤 서비스를 열어 줄지는 별도의 접근 정책, 곧 인가(authorization)로 정합니다.
흔히 인증서에 역할(role)을 담고, ECU가 역할마다 허용할 서비스를 정해 두는 방식을 씁니다. 그러면 공장 작업자, 협력사 개발자, 정비소, 애프터마켓 사용자, 차량 소유자처럼 주체마다 다른 권한을 줄 수 있고, 인증서의 유효 기간으로 그 권한의 기한도 정할 수 있습니다.
두 가지 방식
| 방식 | 내용 | 특징 |
|---|---|---|
| APCE(PKI 인증서 교환) | 진단 클라이언트가 인증서를 제출하고, ECU는 미리 넣어 둔 루트 인증서의 공개키로 검증 | ECU에 공유 비밀이 없음, 인증서 발급과 폐지 체계가 필요 |
| ACR(챌린지 응답) | 미리 공유한 대칭키나 미리 넣어 둔 공개키로 챌린지에 응답 | PKI 없이 가능, 키 유출과 폐지가 숙제 |
두 방식 모두 ECU만 진단 클라이언트를 확인하는 단방향과 서로를 확인하는 양방향이 있습니다.
APCE는 이렇게 동작합니다
- 진단 클라이언트가 백엔드 PKI에서 자기 역할이 담긴 인증서를 발급받습니다.
- 클라이언트가 인증서를 ECU에 보냅니다(verifyCertificateUnidirectional 또는 verifyCertificateBidirectional).
- ECU는 미리 넣어 둔 루트 공개키로 인증서의 서명을 검증하고, 응답으로 챌린지(난수)를 돌려줍니다.
- 클라이언트는 인증서에 대응하는 개인키로 챌린지에 서명해 보냅니다(proofOfOwnership).
- ECU는 인증서 안의 공개키로 서명을 검증해 클라이언트가 그 인증서의 주인임을 확인합니다. 그다음 인증서의 역할에 따라 접근 정책이 허용하는 서비스를 엽니다.
무엇이 달라지나
| 항목 | 0x27 | 0x29(APCE) |
|---|---|---|
| 권한 단위 | 보안 수준 | 인증서의 역할에 따른 접근 정책(구현에서 정의) |
| ECU가 가진 것 | 대칭키 방식이면 진단기와 같은 비밀 | 루트 공개키 |
| 진단 클라이언트가 가진 것 | key 계산에 필요한 비밀 정보 | 자기 개인키와 인증서 |
| 기한 | 없음 | 인증서 유효 기간 |
| 접근 주체 | 0x27 자체로는 증명하지 않음 | 인증서로 식별해 기록할 수 있음 |
| 권한 회수 | 비밀 교체(공유 범위의 차량과 진단기에 영향) | 인증서 폐지, 짧은 유효 기간 |
0x27은 key 계산 알고리즘을 정하지 않으므로, 표의 0x27 열은 많이 쓰이는 대칭키 구현을 기준으로 했습니다.
ECU가 가진 루트 공개키는 비밀은 아니지만, 공격자가 자기 공개키로 바꿔치기하면 모든 검증이 무너집니다. 그래서 루트 공개키는 바꿀 수 없는 저장 영역이나 HSM 같은 하드웨어 보호 보안 환경(HPSE)에 두어 무결성을 지켜야 합니다.
소프트웨어 플랫폼이 지원하는 범위도 확인해야 합니다
AUTOSAR Classic Platform의 진단 모듈(Dcm)도 0x29를 지원합니다. R24-11 명세에 따르면 Dcm은 인증서 확장 필드에서 역할과 허용 서비스 목록(white list)을 읽어 진단 연결마다 접근 제어에 쓰며, 어떤 확장 필드를 읽을지는 설정으로 정합니다. 인증서 저장과 검증은 키 관리 모듈(KeyM)에 맡깁니다. 다만 지원하는 것은 PKI 방식뿐이며, 챌린지 응답 방식(ACR)과 세션 키 교환은 지원하지 않는다고 명시합니다. 표준이 허용하는 기능과 실제로 쓰는 플랫폼이 지원하는 기능이 다를 수 있으니, 설계 전에 확인해야 합니다.
5. 0x29를 도입할 때 부딪히는 문제
0x29는 0x27의 구조적 한계를 상당 부분 풀어 주지만, 그만큼 새로운 숙제가 생깁니다.
인증서를 발급하고 거두는 체계
APCE의 전제는 인증서를 발급하고 폐지하는 PKI입니다. 누가 어떤 역할의 인증서를 받을 수 있는지, 전국의 정비망에 어떻게 배포하는지, 인터넷이 닿지 않는 정비 환경에서는 어떻게 하는지, 진단기의 개인키는 어디에 보관하는지를 정해야 합니다. 차 안의 ECU가 폐지 목록을 실시간으로 확인하기는 어렵기 때문에, 유효 기간을 짧게 잡아 폐지의 부담을 줄이는 설계를 함께 검토합니다.
믿을 수 있는 현재 시각
유효 기간을 확인하려면 ECU가 현재 시각을 알아야 합니다. 그 시각을 어디서 받아 오는지, 공격자가 시각을 조작해 만료된 인증서를 되살릴 수는 없는지도 따져야 합니다. 0x27에는 없던 질문입니다.
ECU 자원과 작업 시간
공개키 서명 검증은 대칭키 계산보다 훨씬 무겁습니다. 암호 가속기가 있는 HSM을 쓸 수 있는지, 수백 바이트가 넘는 인증서를 CAN으로 주고받는 시간이 생산과 정비 공정에 부담이 되지 않는지 확인해야 합니다.
인증 뒤의 메시지
0x29는 연결을 연 주체를 확인할 뿐, 그 뒤에 오가는 요청 하나하나에 서명을 붙이지는 않습니다. 표준에는 인증 과정에서 세션 키를 만들어 보안 데이터 전송(SecuredDataTransmission, 0x84)에 쓰는 선택 기능이 있지만, 앞서 본 AUTOSAR Dcm은 이를 지원하지 않습니다. 같은 버스에서 진단 클라이언트의 주소를 흉내 낼 수 있는 공격자라면, 인증된 연결에 요청을 끼워 넣을 여지가 남습니다. 실제로 가능한지는 진단 연결을 어떻게 관리하는지, 게이트웨이가 어느 경로의 진단 요청을 받아 주는지에 달려 있습니다. 그래서 다른 장치를 겹쳐 씁니다.
- 이더넷 기반 진단(DoIP, ISO 13400-2)은 2019년판부터 TLS 연결을 선택 기능으로 두었고, 현행 2025년판(제3판)도 같습니다.
- 작업이 끝나면 인증을 해제(deAuthenticate)하고, 일정 시간 요청이 없으면 인증 상태가 풀리도록 설계합니다.
- 게이트웨이가 진단 요청이 들어올 수 있는 경로를 제한하고, 침입 탐지 기능이 비정상적인 진단 시도를 기록합니다.
독립 정비업체의 접근권
진단 접근을 잠그는 일은 수리할 권리와 부딪칠 수 있습니다. EU 사법재판소는 2023년 10월 Carglass 사건(C-296/22)에서, 제조사가 독립 정비업체의 OBD 접근에 사전 등록이나 제조사가 지정한 서버 연결처럼 형식승인 규정에 없는 조건을 붙일 수 없다고 판단했습니다. 이후 EU는 위임규정 (EU) 2026/699로 형식승인 규정 (EU) 2018/858의 부속서 X를 고쳐, 2026년 6월 23일부터 제조사가 쓸 수 있는 보안 조치의 조건과 절차를 부록 4로 정했습니다. 핵심은 접근의 성격과 결과에 따라 요구할 수 있는 것이 달라진다는 점입니다.
| 접근 유형 | 제조사가 요구할 수 있는 것 |
|---|---|
| 고장 코드 읽기, VIN 읽기, 배출가스 규정상 범용 스캔 도구에 열어 둬야 하는 데이터 읽기와 고장 코드 지우기 | 진단기 인증도 요구할 수 없음 |
| 그 밖의 접근 | 진단기와 진단기 제조사의 인증, 자격 증명을 받을 때 한 번의 온라인 연결, VIN과 진단기 식별자 기록 |
| 차량을 바꾸는 접근(액추에이터 구동, 기능 시험 루틴, 정비 알림 초기화, 부품 교체와 초기화 등) | 위에 더해 정비업체 인증, 수행한 진단 작업(서비스 ID와 하위 기능)과 시각 기록 |
| 정비 뒤에도 차량의 동작이 달라지는 변경(소프트웨어 재프로그래밍, 변형 코딩 등) | 위에 더해 작업하는 동안 계속 온라인 연결, 재프로그래밍은 작업자 개인 인증 |
정비업체와 작업자의 신원은 가명 처리해 전달하고, 세부 조건과 예외는 부록 4를 따릅니다. 또한 제조사의 보안 조치는 필요하고 비례적인 범위를 넘어 접근을 막아서는 안 되며, 독립 정비업체에 정식 정비망보다 더 많은 제한을 둘 수 없습니다.
이 규정이 0x29 같은 특정 UDS 서비스를 요구하는 것은 아닙니다. 규정이 허용하는 접근 통제의 범위와 그것을 구현하는 기술은 별개입니다. 다만 0x29로 역할을 나눈다면 위 표의 구분이 역할과 접근 정책을 설계하는 좋은 출발점이 됩니다. 고장 코드 읽기처럼 막아서는 안 되는 기능까지 인증 뒤에 두지 않았는지, 독립 정비업체가 정식 정비망과 같은 조건으로 접근할 수 있는지 함께 점검해야 합니다.
6. 플래시 프로그래밍: 인증만으로는 부족하다
UDS로 ECU 소프트웨어를 다시 쓰는 플래시 프로그래밍은 가장 위험한 진단 기능입니다. 프로그래밍 세션에서 RequestDownload(0x34)와 TransferData(0x36)를 쓰려면 먼저 인증을 통과해야 합니다. 하지만 인증된 진단 클라이언트를 공격자가 손에 넣는 경우까지 생각하면, 인증 뒤에도 다음 장치가 필요합니다.
- 주소 범위 검사: 지우거나 쓰면 안 되는 영역(플래시 부트로더, 키 저장 영역 등)을 겨냥한 요청은 거부합니다.
- 업로드 기능 제거: RequestUpload(0x35)는 가능하면 빼서, 인증된 진단 클라이언트를 손에 넣은 공격자조차 소프트웨어를 빼내지 못하게 합니다. 메모리를 주소로 직접 읽는 서비스(ReadMemoryByAddress, 0x23)도 같은 기준으로 검토합니다.
- 서명 검증 뒤에만 유효 표시: 새 이미지는 디지털 서명을 검증한 뒤에만 유효로 표시합니다. 소프트웨어와 펌웨어뿐 아니라 캘리브레이션 데이터도 대상입니다. 캘리브레이션 변조는 가볍게 보기 쉽지만, 안전에 영향을 줄 뿐 아니라 배출가스 규제 위반으로 이어질 수 있습니다.
- 중단에 대비할 것: 업데이트 도중 전원이나 통신이 끊겨도, 공격자가 일부러 전송을 끊어도 ECU가 영구적으로 복구할 수 없는 상태가 되어서는 안 됩니다. 정상 애플리케이션을 실행할 수 없더라도 보호된 플래시 부트로더나 별도 복구 경로로 다시 프로그래밍할 수 있어야 합니다.
- 플래시 라이브러리 정리: 프로그래밍이 끝난 뒤에도 플래시 쓰기와 지우기 함수가 런타임에 남아 있으면, 악성 애플리케이션이 이를 불러 내용을 바꾸거나, 지우기를 반복해 플래시를 닳게 만들 수 있습니다. 필요 없어지면 라이브러리를 내리고 지우기 기능을 잠급니다.
무선 업데이트(OTA)도 차량 안에서는 결국 이 경로를 거치는 경우가 많습니다. 소프트웨어 업데이트를 안전과 보안 양쪽에서 관리하는 방법은 SW 업데이트 활동에서 기능안전과 사이버보안의 연계 활동에서 다뤘습니다.
7. 마무리: 진단 보안 점검 질문
진단 기능은 개발과 정비를 위한 편의 기능이 아니라 차량에서 가장 강력한 권한입니다. 0x27에서 0x29로 옮기는 일은 자물쇠 하나를 바꾸는 일이 아니라, 누구에게 어떤 권한을 얼마 동안 줄지 정하고 운영하는 체계를 갖추는 일입니다. 다음 질문으로 지금의 설계를 점검해 보시기 바랍니다.
- UDS, XCP, 공급사 고유 루틴까지 포함한 진단 기능 목록이 있고, 양산에서 빼는 항목이 정해져 있습니까?
- 위험한 서비스마다 차량 상태 조건이 있고, 게이트웨이에서도 거릅니까?
- 0x27을 계속 쓴다면, seed는 충분히 긴 난수이고 key 계산은 표준 암호이며 비밀은 ECU나 차량마다 다릅니까?
- 0x29를 도입한다면 역할과 접근 정책, 인증서 발급과 폐지, 유효 기간, 시각의 출처까지 설계했습니까?
- EU에 차량을 판다면, 고장 코드 읽기처럼 막아서는 안 되는 기능을 인증 뒤에 두지 않았습니까?
- 인증 뒤의 메시지는 TLS, 인증 해제, 시간 초과 같은 장치로 보호합니까?
- 플래시 프로그래밍은 서명 검증, 주소 범위 검사, 업로드 기능 제거, 중단 뒤 복구 경로를 갖췄습니까?
- 진단 인터페이스가 TARA에서 공격 경로로 분석되어 있습니까?
이미 판매된 차량에는 0x27이 오래 남습니다. 새 플랫폼에 0x29를 도입하는 일과 함께, 기존 0x27 구현이 위의 조건을 지키는지 점검하는 일도 병행하시기를 권합니다.
참고 문헌
- 아흐마드 MK 나세르 지음, 주백수, 신승환 옮김, 『자동차 사이버보안 엔지니어링 핸드북』, 에이콘출판, 2026. 3장 차량 구성요소에 대한 위협 환경, 8장 차량 수준 보안 통제.
- ISO 14229-1:2026, Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer, 제4판. Authentication(0x29)은 ISO 14229-1:2020(제3판)에 추가.
- ISO 13400-2:2025, Road vehicles, Diagnostic communication over Internet Protocol (DoIP), Part 2: Transport protocol and network layer services, 제3판. TLS 선택 기능은 ISO 13400-2:2019부터.
- J. Van den Herrewegen, F. D. Garcia, Beneath the Bonnet: A Breakdown of Diagnostic Security, ESORICS 2018, Springer, pp. 305-324.
- AUTOSAR, Specification of Diagnostic Communication Manager, Classic Platform R24-11, 7.4.2.10절.
- A. Geynis, New UDS Authentication: Enhanced Security, Familiar Challenges, Embedded Computing Design, 2024-11-01.
- Commission Delegated Regulation (EU) 2026/699, 규정 (EU) 2018/858 부속서 X 개정, 부록 4 OBD 정보 접근 조건과 절차.
- Council of the European Union, ST 7952/26 ADD 1, C(2026) 1811 final 부속서(위의 위임규정 채택 문안), 2026-04-01.
- Noerr, Developments following the ECJ’s decision in the Carglass case: Delegated Regulation (EU) 2026/699 sets out new guidelines for secure gateways, OBD access and RMI, 2026-06-22.
이 글은 2026년 10월 8일 기준 공개 자료를 바탕으로 정리했습니다. 0x27과 0x29의 세부 동작과 하위 기능 구성은 ISO 14229-1 원문과 각 제조사의 진단 명세를 따르며, EU 규정 관련 내용은 법률 자문을 대신하지 않습니다.
관련 서비스
진단 인터페이스를 포함한 TARA와 보안 요구사항 정리부터 검증까지 사이버보안 대응을 고민 중이시라면, 세온이앤에스의 접근 방식을 확인해 보세요.
관련 영상
이 글의 핵심을 영상으로도 정리했습니다.