[DCM] Security Access 설정 방법 (DcmDspSecurityRow 실무 설정)

자동차 ECU에는 단순 조회 기능만 존재하는 것이 아니다.

실제 차량에서는 특정 데이터를 수정하거나 ECU 내부 기능을 강제로 실행해야 하는 경우가 존재한다.

 

예를 들어 다음과 같은 기능들이 있다.

• VIN 쓰기
• Variant Coding
• Factory Mode 진입
• EEPROM/NvM 데이터 변경
• ECU Reset
• RoutineControl 실행
• Flash Download

이런 기능들을 아무나 사용할 수 있게 열어두면 매우 위험하다.

외부 진단기만 연결해도 차량 설정을 변경하거나 ECU 상태를 바꿀 수 있기 때문이다.

 

그래서 UDS 진단에서는 특정 서비스에 보안 절차(Security Access)를 걸어두고,

인증에 성공한 경우에만 기능을 허용하도록 만든다.

 

AUTOSAR DCM에서는 이러한 보안 기능을 DcmDspSecurity 설정을 통해 관리하며,

실제 Security Level 하나하나를 DcmDspSecurityRow 컨테이너 형태로 구성하게 된다.

 

이번 글에서는 mobilgene 기준으로 Security Access의 개념부터 실제 DcmDspSecurityRow 설정 의미, 그리고 실무 동작 흐름까지 전체적으로 정리해본다.

 

Security Access(0x27)는 왜 필요한가?

 

UDS 진단 서비스를 처음 접하면 보통 0x22(ReadDataByIdentifier) 같은 조회 서비스부터 사용하게 된다.

예를 들어 Tester가 22 F1 90 같은 UDS 요청을 보내면 ECU는 차량 VIN 값을 응답하게 된다.

 

하지만 만약 VIN을 수정하는 0x2E(WriteDataByIdentifier) 서비스를 아무 제한 없이 사용할 수 있다면 어떻게 될까?

외부 진단기만 연결해도 차량 식별 정보를 변경할 수 있게 된다.

실제로 차량 ECU에는 보호가 반드시 필요한 기능들이 매우 많다.

• 차량 옵션 변경
• Calibration 값 수정
• Flash 다운로드
• 공장모드 진입
• 모터 강제 구동
• EEPROM 초기화

이런 기능들은 일반 사용자가 접근하면 안 되기 때문에 ECU는 특정 조건을 만족한 경우에만 허용하도록 만든다.

그 대표적인 방식이 바로 0x27 Security Access 이다.

 

Security Access는 어떻게 동작할까?

 

많은 초보자들이 Security Access를 단순 비밀번호 입력 정도로 생각한다.

하지만 실제 ECU에서는 대부분 Seed / Key 구조를 사용한다.

 

동작 흐름은 아래와 같다.

Tester → Seed 요청
ECU → Seed 응답
Tester → Key 계산
Tester → Key 전송
ECU → Key 검증
Unlock 성공

 

여기서 중요한 점은 ECU가 매번 다른 Seed 값을 내려준다는 것이다.

 

즉 단순히 고정 비밀번호를 사용하는 것이 아니라,

ECU가 제공한 Seed 값을 기반으로 특정 알고리즘을 이용해 Key 값을 계산해야 한다.

 

예를 들어 ECU가 아래와 같은 Seed를 내려주면:

12 34 56 78

 

Tester는 내부 알고리즘을 이용해서:

12 34 56 79

 

같은 Key 값을 계산해 ECU에 전송한다.

그리고 ECU 내부 계산 결과와 동일하면 Unlock이 성공하게 된다.

 

실제 양산 차량에서는 단순 +1 수준이 아니라 제조사별 암호화 알고리즘이나 Crypto 모듈이 사용된다.

 

실제 차량에서는 어떤 순서로 사용할까?

 

실무에서는 보통 아래 순서로 움직인다.

0x10 Session Control
→ 0x27 Security Access
→ 0x2E / 0x31 수행

 

즉, 먼저 Extended Session 같은 특수 세션으로 진입한 뒤, Security Unlock을 수행하고,

그 이후에 실제 쓰기나 Routine 서비스를 사용하는 형태이다.

 

왜 이렇게 동작할까?

이유는 ECU 기능을 단계별로 보호하기 위해서이다.

일반 운행 상태에서는 단순 조회 기능만 허용하고,

개발 모드, 공장 모드, 프로그래밍 모드 같은 특수 상태에서만 위험한 기능을 허용하는 것이다.

 

즉, Session과 Security는 거의 항상 함께 움직인다.

 

mobilgene에서 Security 설정 위치

 

mobilgene 기준으로 Security 설정은 아래 위치에서 확인할 수 있다.

 

여기서 L9 하나가 실제 Security Level 하나를 의미한다.

즉, AUTOSAR 개념으로 보면 현재 L9 자체가 하나의 DcmDspSecurityRow 라고 이해하면 된다.

 

프로젝트에서는 보통 Security Level을 여러 개 나누어 사용한다.

예를 들어

Security Level	용도
L1	일반 개발
L3	Factory Mode
L5	Flash Programming
L9	OEM 전용 기능

 

이런 형태로 구성하는 경우가 많다.

즉, ECU 내부 기능별로 접근 권한을 구분하는 개념이라고 보면 된다.

 

실제 DcmDspSecurityRow 설정 항목 설명

 

처음 L9 설정 화면에 들어가 보면 생각보다 항목이 많다.

 

단순히 Seed/Key 정도만 설정할 것 같지만,

실제로는 실패 횟수 제한, 재시도 제한, 보안 함수 연결까지 모두 관리한다.

 

이번에는 실제 설정 항목들이 어떤 의미를 가지는지 하나씩 살펴보자.

 

Attempt Counter Enabled

이 설정은 Security 실패 횟수를 관리할지 여부를 의미한다.

만약 이 기능이 없다면 외부에서 무한정 Key 값을 계속 시도할 수 있다.

즉, Brute Force 방식 공격이 가능해진다.

그래서 일반적으로는 일정 횟수 이상 실패하면 일정 시간 동안 Security Access를 막도록 구성한다.

실제 양산 ECU에서는 거의 대부분 활성화되어 있다.

 

Delay Time

이 값은 Security 인증 실패 이후 재시도 제한 시간을 의미한다.

현재 설정은 180초이므로, Key 입력 실패 후 3분 동안 다시 Unlock 시도를 막는다는 의미이다.

실무에서는 보안 강화를 위해 매우 중요한 설정 중 하나이다.

 

Num Att Delay

이 설정은 실패 허용 횟수를 의미한다.

즉, 현재 설정은 3번까지 실패를 허용하고, 이후 Delay Time을 적용한다는 의미가 된다.

실제로 CANoe 테스트 중 Key 계산이 잘못되면 이 조건에 걸려서 Unlock이 막히는 경우가 매우 많다.

 

Seed Size / Key Size

이 설정은 Seed와 Key 데이터 크기를 의미한다.

현재 설정은 Seed = 8Byte, Key = 8Byte 구조라는 의미이다.

여기서 중요한 점은 ECU와 Tester가 반드시 동일한 크기를 사용해야 한다는 것이다.

예를 들어 ECU는 8Byte를 기대하는데 Tester는 4Byte 전송같은 상황이면 Unlock은 실패하게 된다.

실무에서 매우 자주 발생하는 문제 중 하나이다.

 

Level
이 값은 현재 Security Level 번호를 의미한다.

초보자들이 가장 헷갈리는 부분 중 하나인데, 보통 UDS에서는 홀수/짝수 SubFunction 규칙을 사용한다.

 

예를 들어

SubFunction	의미
0x09	Seed Request
0x0A	Send Key

 

형태로 사용된다.

즉, 현재 설정은 L9 Security Level과 연결된 구조라고 보면 된다.

 

Use Port

USE_ASYNCH_CLIENT_SERVER 방식은 Security 처리를 비동기(Client/Server) 형태로 수행하겠다는 의미이다.

즉, DCM이 직접 즉시 결과를 반환하는 구조가 아니라, RTE를 통해 특정 Runnable이나 외부 보안 처리 함수를 호출한 뒤 결과를 기다리는 방식으로 동작하게 된다.

 

왜 이런 구조를 사용할까?

단순한 테스트용 알고리즘이라면 Seed를 생성하거나 Key를 비교하는 작업이 매우 빠르게 끝난다.

하지만 실제 양산 차량에서는 보안 처리가 생각보다 복잡한 경우가 많다.

 

예를 들어:

• HSM(Hardware Security Module)
• Crypto Stack
• 외부 보안 IC
• 제조사 암호화 라이브러리

같은 모듈과 연동되는 경우에는 내부 암호화 연산이나 하드웨어 접근 시간이 필요할 수 있다.

이때 만약 동기(Sync) 방식으로 처리하게 되면 DCM이 해당 작업이 끝날 때까지 계속 대기하게 되고, 경우에 따라 진단 응답 지연 문제가 발생할 수 있다.

 

그래서 AUTOSAR에서는 비동기 Client/Server 구조를 사용하여

DCM은 보안 처리 요청만 전달하고,

실제 암호화 연산은 별도의 Runnable 또는 보안 모듈에서 수행한 뒤,

완료 결과만 다시 전달받는 형태로 동작하게 된다.

 

즉, USE_ASYNCH_CLIENT_SERVER 설정은 단순 옵션이 아니라, 실제 ECU 보안 처리 구조와 연결되는 중요한 설정 중 하나라고 볼 수 있다.

 

정리

 

AUTOSAR DCM에서 Security Access는 단순히 Seed와 Key를 주고받는 기능 정도로 끝나는 것이 아니다.

실제로는 ECU 내부 기능을 보호하기 위한 핵심 보안 구조 중 하나이며, 대부분의 중요 진단 기능들과 직접 연결되어 있다.

 

특히 실제 차량에서는 단순 조회 기능 외에도 다양한 위험 기능들이 존재한다.

예를 들어 DID 쓰기(WDBI), RoutineControl 실행, Flash Programming, Factory Mode 진입 같은 기능들은 ECU 상태를 변경하거나 차량 동작 자체에 영향을 줄 수 있기 때문에 반드시 보안 인증 이후에만 허용되도록 구성하는 경우가 많다.

 

그래서 실무에서는 Security Access가 단독으로 존재하는 것이 아니라 Session Control, DID 접근 권한, RoutineControl, Download/Upload 같은 기능들과 함께 동작하게 된다.

 

또한 실제 디버깅에서는 단순히 Seed/Key 흐름만 이해해서는 부족하다.

예를 들어 Unlock이 실패했을 때도 단순히 “Key가 틀렸다” 수준으로 끝나는 것이 아니라,

• 현재 ECU가 어떤 Session 상태인지
• 현재 활성화된 Security Level이 무엇인지
• DID가 어떤 권한을 요구하는지
• NRC 응답 코드가 무엇인지
• Attempt Counter가 잠긴 상태는 아닌지

같은 여러 조건들을 함께 확인해야 실제 원인을 찾을 수 있다.

 

특히 프로젝트를 진행하다 보면 Unlock 자체는 성공했는데 특정 DID 접근이 실패하거나, Session 조건이 맞지 않아 서비스가 거부되는 상황을 매우 자주 경험하게 된다. 그래서 실무에서는 Security Access를 단순 보안 기능이 아니라 ECU 전체 진단 흐름의 일부로 이해하는 것이 중요하다.

 

결국 Security Access는 단순 진단 옵션이 아니라,

ECU 내부 기능을 보호하기 위한 핵심 보안 메커니즘이라고 볼 수 있다.

 

특히 AUTOSAR DCM을 공부하다 보면 이후 등장하는 대부분의 진단 기능들이

Session, Security, DID 권한과 서로 연결되어 움직이게 되므로,

초기에 전체 흐름을 함께 이해해두는 것이 매우 중요하다.