지난 호 ‘EVITA 프로젝트의 이해(1)’에서는 EVITA의 배경과 목적, 시큐리티 프레임워크, 그리고 하드웨어 보안 모듈인 HSM에 대해 알아봤다. 이번에는 EVITA의 소프트웨어 아키텍처를 소개한다.
소프트웨어 아키텍처는 세가지 특징을 갖는데, 첫째는 모듈식 보안 메커니즘을 통한 확장성, 둘째는 보안 기능의 캡슐화 및 추상화, 셋째는 정책 기반의 구성이다.
모듈식 보안 컴포넌트
EVITA 보안 프레임워크의 목표는 특정 보안 컴포넌트의 재사용이다. 이를 통해 개발 비용과 복잡도를 최소화할 수 있다. 시큐리티 프레임워크는 온보드 아키텍처 및 애플리케이션의 제약 사항들과 보안 요구사항에 따라 각각 설정 가능하도록 하는 전용 보안 메커니즘 모듈을 제공한다. 유스케이스는 보안 요구사항들의 서브셋을 동시에 요구할 수 있기 때문에, 모듈형 구조는 보안 컴포넌트 재사용의 이점이 있다. 보안 기능의 모듈식 구성과 배치는 각 유스케이스 및 온보드 아키텍처 설정에 따른 불필요한 기능의 배치를 방지할 수 있다.
보안 기능의 추상화
보안 프레임워크는 2계층의 추상화된 보안 메커니즘 모듈을 제공한다. 보안 모듈들은 다른 보안 모듈에게 각각의 보안 인터페이스를 제공하며, 이는 API를 통해 서로의 서비스를 공유할 수 있도록 한다. 이때 이 인터페이스들은 보안 메커니즘을 통합하는 애플리케이션 개발자에게 추가적인 추상화 레이어를 통해 제공된다. 그림 2에서 설명하듯이 특정 보안 기능을 제공하는 보안 모듈들은 Security module API를 통해 한 번 추상화되고, 이는 Application developer API를 통해 다시 한 번 추상화된다.
따라서 보안 모듈의 상호 의존 관계는 캡슐화되어 애플리케이션 개발자에게는 보이지 않게 된다. Application developer API는 최소한의 필요한 인터페이스만 제공한다. 물론 필요에 의해 Security module API를 직접 사용할 수 있다. Security module API 및 Security Module은 애플리케이션의 요구사항에 따라 다른 구현이 보안 모듈에 연결될 수 있도록 하는 방식으로 설계된다. 이러한 구현은 추상화에 의해 다른 모듈의 변경이나 애플리케이션 인터페이스의 변경 없이 Security module API를 통해 프레임워크로 연결될 수 있다.
정책 기반의 보안 구성
보안 기능의 적용 용이성 및 유연성을 최대로 하기 위해, 모든 보안 모듈은 각각의 보안 정책을 준수하고 시행할 수 있도록 구성돼야 한다. 이러한 보안 정책에는 허가, 프라이버시, 인증, 침입 감지 및 대응 정책 등이 있다. 허가 정책은 특정 개체의 접근이나 특정 리소스 사용에 대한 허가 정도를 구체화시키고, 프라이버시 정책은 데이터 및 정보의 공개 수준을 규정한다.
인증 정책은 어떠한 인증 방식을 사용할 것인지, 예를 들어 패스워드를 사용할 것인지 스마트카드를 사용할 것인지 등을 정의한다. 침입 감지 정책은 특정 공격 시나리오와 공격 학습을 정의하며, 침입 대응 정책은 감지된 공격 종류에 대해 어떠한 대응 방식을 사용할 것인지를 정의한다.
소프트웨어 시큐리티 모듈
소프트웨어 시큐리티 프레임워크의 모듈들은 각 ECU들의 역할과 요구사항 및 성능에 맞게 배치되어 사용된다. 각 모듈을 간략하게 소개한다.
EAM(Entity Authentication Module)
식별, 계정 관리, 싱글 사인 온(Single Sign-On, SSO)/사인 아웃 구현, 프라이버시 보호 메커니즘 등 인증 관련 태스크를 제공하며, 다양한 인증 메커니즘을 통합한다.
CCM(Communication Control Module)
보안 통신을 위한 High-level 인터페이스를 제공한다. 이 모듈은 모든 내부 프로세스 통신과 모든 차량 통신, 차량 내부 및 외부 개체들 사이의 통신을 보호하고 제어한다. 그러므로 사실상 CCM은 상호 호출 및 통신을 위한 모든 시큐리티 모듈에서 사용된다.
PDM(Policy Decision Module)
정책의 관리 및 접근과 정책 결정에 대한 인터페이스를 제공한다. 그리고 추가적으로 방화벽과 같이 특수화된 PDM에게 결정을 위임하기도 한다. PEP(Policy Enforcement Points)는 리소스에 대한 접근 요청을 받고 접근 제어 결정을 시행하는 포인트로, 독립적인 모듈로 존재하는 것이 아니라 추상적인 서브 PDM으로 동작한다.
SWD(Security Watchdog Module)
침입 감지 및 대응에 대한 메커니즘을 제공한다. SWD는 보안 파라미터를 모니터하고 그에 상응하는 보안 응답을 발생시킨다.
PIM(Platform Integrity Module)
EVITA HSM 서비스와 관련된 보안 서비스를 제공한다.
SSM(Secure Storage Module)
데이터의 보안 저장을 위한 서비스를 제공한다. 이 모듈은 공격자의 접근이 가능한 비휘발성 데이터 스토리지에 대한 보안 요구사항(기밀성, 무결성/진위성 등) 및 기능적 요구사항을 제공한다.
CRS(Cryptographic Services Module)
모든 기본적인 암호화 기능 및 프리미티브에 대한 인터페이스를 제공한다. 암호화 서비스를 필요로 하는 시큐리티 모듈 또는 프로그램에 통합되기 때문에 모듈이라기 보다는 라이브러리에 가깝다.
각 보안 모듈은 각각의 자체 내부 API를 제공하고, 이것은 서로 다른 보안 모듈에서 사용될 수 있다. 예를 들어 CCM은 암호화된 인증 통신 채널을 제공하기 위해 EAM과 PDM 서비스를 이용한다. Low-level 보안 메커니즘과 프로토콜은 전용 애플리케이션의 요구사항에 맞는 플러그-인 인터페이스를 통해 통합된다. 보안 기능 통합을 용이하게 하기 위해 최소한의 내부 인터페이스만이 제공되며, 이러한 인터페이스는 보안기능의 복잡성을 추상화한다.
이렇게 모듈화되고 확장 가능성을 지닌 시큐리티 아키텍처는 애플리케이션 개발자에게 보안 서비스를 쉽게 이용할 수 있도록 한다. 또한 보안 요구사항과 온-보드 아키텍처 설계에 따른 보안 서비스의 구축 및 구성에 대한 유연성을 제공하며, 새로운 요구사항에 따른 보안 업데이트 적용도 유연하게 한다.
<저작권자 © AEM. 무단전재 및 재배포, AI학습 이용 금지>