AAOS SDV - 처음부터 안전한 설계

Google은 제품이 설계상 안전해야 한다고 생각합니다. 따라서 기존의 시장 검증 플랫폼에서 소프트웨어 정의 차량용 Android Automotive 운영체제 (AAOS SDV)를 빌드하고 Cuttlefish와 같은 가상화 기술을 활용합니다. 출시 공지사항에서는 기능에 중점을 두었지만 이 블로그 게시물에서는 몇 가지 보안 개념을 간략하게 설명합니다.

기반: 도메인 격리

공동 호스팅 인스턴스를 격리하기 위한 가상화

전자 제어 장치 (ECU)를 단일 칩으로 통합하는 현재 추세는 여러 도메인을 나란히 실행하여 격리를 줄입니다.

AAOS SDV 인스턴스는 내부 격리 메커니즘을 제공하지만 논리 도메인을 독립적으로 실행하는 것이 더 나은 경우가 많습니다. 예를 들어 클러스터와 인포테인먼트 시스템에는 서로 다른 요구사항이 있습니다. Google에서는 가상 머신을 사용하여 여러 인스턴스를 병렬로 실행하여 공유가 명시적으로 유지되고 격리가 기본 동작이 되도록 합니다.

상속된 Android 보안

AAOS SDV는 개인 정보 보호 가상 머신 (pVM)에 최적화된 최소한의 Android 버전인 Microdroid에서 진화했습니다. 이 계통은 Android 플랫폼 엔지니어에게 이미 알고 있는 확립된 보안 기능을 제공합니다.

프로세스 격리 및 기본적으로 거부

AAOS SDV는 Android의 사용자 ID (UID) 기반 격리 모델을 따라 각 애플리케이션의 샌드박스를 설정합니다. 각 서비스는 액세스 권한, 데이터 디렉터리, 기타 제한사항을 관리하기 위해 고유한 UID가 있는 전용 프로세스에서 실행됩니다. Google에서는 휴대용 운영체제 인터페이스 (POSIX) 기능을 사용하여 작업을 엄격하게 제한하고 이를 보안 강화 Linux (SELinux)와 결합하여 '기본적으로 거부' 자세를 적용합니다. 이 접근 방식은 각 서비스를 필요한 최소한으로 제한하므로 구성이 누락되면 과도한 권한이 있는 시스템을 만드는 대신 액세스가 차단됩니다. 이 문서의 뒷부분에서 설명하겠지만 Google은 커뮤니케이션 권한 시스템에도 동일한 전략을 적용합니다.

입증된 취약점 관리

AAOS SDV는 Android의 성숙한 보안 대응 및 취약점 관리 인프라를 통합하여 보안 발견 사항을 식별, 분류, 수정, 공개합니다. 이 수명 주기에는 지속적인 자동 스캔, 연간 심층 침투 테스트, Android 보안 취약점 보고 프로세스를 통한 파트너 중심 인텔리전스가 포함됩니다. 보안팀은 발견된 취약점을 분류하고, 위험에 따라 심각도 등급을 할당하고, 완료될 때까지 해결을 추적합니다. Google은 월간 Android 보안 게시판을 통해 공개 및 출시 정책을 조정하고, 장기적인 플랫폼 복원력을 보장하기 위해 엄격한 정기 보안 감사와 포괄적인 아키텍처 검토를 보완합니다.

무결성: 안전한 소프트웨어 배포

안전한 플랫폼은 프로세스 격리를 보장하는 것 외에도 실행 전에 코드 무결성을 보장해야 합니다. Google에서는 다음과 같은 접근 방식을 통해 소프트웨어 배포를 보호합니다.

인증된 소프트웨어 배포

AAOS SDV는 두 가지 설치 방법을 제공합니다. 먼저 부팅할 때마다 서명을 검증하는 읽기 전용 시스템, 제품 또는 공급업체 파티션에 직접 소프트웨어를 설치합니다. 이렇게 하면 기본 시스템 구성요소가 보호됩니다.

둘째, 서비스에 Android Pony EXpress (APEX) 패키지를 활용합니다. 각 APEX는 소프트웨어와 종속 항목을 캡슐화하여 패키지를 필수 서명 검증이 있는 파티션으로 취급합니다. AAOS SDV에서 APEX는 코드 서명을 지속적인 하드웨어 적용 계약으로 취급합니다. APEX는 다음 네 가지 핵심 요소를 통해 악성 코드 실행을 완화합니다. 

1. 변경 불가 스토리지

• 메커니즘: Android 커널은 apex_payload.img 파일을 읽기 전용 루프백을 사용하여 원시 저장 장치로 직접 루프하고 엄격한 MS_RDONLY 플래그로 마운트합니다.
• 더 안전한 이유: 파일이 차량의 저장소에 압축 해제되지 않으므로 OS에 쓰기 경로가 노출되지 않습니다. 공격자가 루트 권한을 획득하더라도 파일 시스템 레이어에서 모든 쓰기 명령을 거부하므로 실행 중인 APEX 코드를 수정할 수 없습니다.

2. 암호화 무결성

• 메커니즘: 암호화 서명은 전체 파일 시스템 이미지의 머클 트리를 검증합니다.
• 보안성이 더 높은 이유: 커널은 블록별 dm-verity를 사용하여 4KB 데이터 블록마다 서명을 즉시 확인합니다. 공격자가 플래시 메모리의 원시 블록을 수정하면 커널이 해시 불일치를 감지하고 즉시 실행을 중단합니다.

3. 엄격한 격리

• 메커니즘: 프로세스 격리 섹션에 설명된 프로세스 격리 규칙을 적용하여 샌드박스를 만듭니다. APEX는 /apex 아래에 전용 파티션으로 마운트됩니다.
• 더 안전한 이유: 각 서비스는 자체 사용자 및 데이터 디렉터리를 수신하므로 공유가 명시되지 않는 한 액세스가 제한됩니다. 전용 파티션을 생성하여 Android는 전용 링커 네임스페이스를 설정하므로 명시적으로 노출된 라이브러리만 권한이 없는 시스템 데몬에서 액세스할 수 있어 공격 영역이 최소화됩니다.

4. 원자적 복구

• 메커니즘: APEX는 '활성/백업' 설계를 사용하여 이중 버퍼링 롤백을 지원합니다. 팩토리 플래시된 APEX는 변경 불가능한 /system 파티션에 남아 있고 업데이트는 변경 가능한 /data 파티션에 있습니다.
• 더 안전한 이유: 업데이트가 실패하거나 악성으로 보이는 경우 apexd 데몬은 초기 부팅 중에 '실패'로 표시합니다. 시스템은 심볼릭 링크를 /system 파티션으로 즉시 다시 스왑합니다. 이 원자적 복구를 통해 시스템이 손상된 상태로 유지되지 않습니다.

복원력: 메모리 안전 개발

확인된 로드는 시스템을 외부 수정으로부터 보호하지만 플랫폼 복원력은 기본 코드가 빌드되는 방식에 따라 달라집니다. AAOS SDV용으로 개발된 새로운 구성요소의 경우 메모리 안전이 우선시되었습니다.

Rust를 기본 언어로 사용

AAOS SDV는 빠른 가용성 요구사항이 있는 소규모 시스템을 타겟팅합니다. 따라서 전체 Android 스택에서 빌드할 수 없으므로 범위를 네이티브 프레임워크로 제한했습니다. 분산 시스템에 필요한 인프라를 만들기 위해 기존 인프라 외에 여러 구성요소를 개발하고 Rust를 기본 언어로 채택했습니다. 또한 Google은 Rust를 사용하여 서비스의 비즈니스 로직을 개발하여 파트너가 안전한 소프트웨어를 작성할 수 있도록 지원합니다. 설계상 Rust는 메모리 안전 기능을 활용하여 일반적인 메모리 안전 취약점을 방지하는 동시에 네이티브 코드를 작성할 때 팀 처리량을 지원합니다.

분산 신뢰: 네트워크 및 액세스 제어

소프트웨어 정의 차량에는 격리된 도메인 간의 보안 상호작용이 필요합니다. AAOS SDV 메시 프로비저닝 아키텍처는 모든 통신 엔드포인트의 버전과 작성자를 암호화 방식으로 확인하여 이러한 복잡성을 해결합니다.

기기 및 메시 프로비저닝

AAOS SDV 메시에서는 모든 구성요소의 네트워크 ID를 실제 바이너리 실행 상태에 수학적으로 바인딩하여 인증을 설정합니다. 이 모델은 암시적 소프트웨어 신뢰를 하드웨어 기반 확인으로 대체합니다.

메시 인증은 지속적이고 암호화되도록 설계되었습니다. 이렇게 하면 예를 들어 차량 게이트웨이와 같은 서비스가 올바른 IP 주소가 있다는 이유만으로 손상된 인포테인먼트 VM을 신뢰하는 시나리오가 방지됩니다.

하드웨어로 강제 적용되는 격리 및 자동 격리 프로토콜로 플랫폼을 보호합니다. SDV 메시 내의 피어 기기는 다음 섹션에 자세히 설명된 대로 DICE 기반 인증 및 증명을 사용하여 승인되지 않은 코드 실행 또는 구성 조작을 식별하고 억제합니다.

VM 간 통신을 보호하는 DICE 기반 TLS

호스트의 정체성을 현실에 기반

DICE (Device Identifier Composition Engine)의 황금률: 펌웨어의 단일 코드 줄이 변경되면 (사소한 업데이트나 악성 익스플로잇 포함) 파생된 복합 기기 식별자 (CDI)가 완전히 변경되어 완전히 다른 별칭 키가 생성됩니다.

DICE와 TLS (전송 계층 보안)는 제로 트러스트 아키텍처의 근본적인 과제인 소프트웨어 무결성을 동시에 검증하면서 머신을 인증하는 문제를 해결하기 위해 통합됩니다.

DICE의 하드웨어 기반 식별과 TLS의 암호화된 핸드셰이크를 결합하면 수신 머신이 호출자의 ID와 정확한 소프트웨어 상태를 모두 확인할 수 있습니다.

기존 인증서는 보안 비밀의 소유권만 증명하며 펌웨어 조작을 감지할 수 없습니다. DICE는 측정된 부팅 레이어링을 통해 이 문제를 해결합니다.

• 고유 기기 보안 비밀 (UDS): 제조 중에 생성된 무작위 암호화 보안 비밀입니다. 첫 번째 단계 부트로더만 UDS에 액세스할 수 있으며 다른 모든 소프트웨어와 외부 인터페이스에는 액세스할 수 없습니다.
• 계층화된 측정 (복합 기기 식별자): 하드웨어 ROM은 다음 펌웨어 계층의 정확한 코드 및 구성으로 UDS를 해싱하여 체인을 시작합니다. 이렇게 하면 CDI가 생성되고 각 후속 레이어가 부팅될 때 순차적으로 연결됩니다.

엄격한 액세스 제어는 AAOS SDV 메시 내의 서비스 상호작용을 관리합니다. 모든 AAOS SDV 소프트웨어와 마찬가지로 이러한 액세스 제어는 인증되며 DICE 기반 인증을 통해 기기 수준에서 그리고 메시의 기기 전반에서 무결성이 보호됩니다.

계층화된 액세스 제어

AAOS SDV는 액세스 메커니즘을 손상하지 않고 동적 차량 업데이트를 지원하기 위해 심층 방어 전략을 사용합니다. 이 모델은 두 가지 기본 신뢰 레이어를 사용합니다.

1. 서비스 수준 권한: 특정 VM의 서비스가 메시 전체에서 액세스하거나 노출할 수 있는 특정 리소스를 정의합니다.
2. VM 수준 권한: 특정 VM에서 호스팅되는 모든 서비스의 VM 간 통신 경계를 정의합니다.

이 모델을 사용하면 OEM이 보안과 업데이트 가능성의 균형을 맞출 수 있습니다. 보안에 민감하지 않은 서비스의 경우 허용적인 VM 수준 정책을 사용하면 전체 VM 재배포가 아닌 경량 APEX 업데이트를 통해 설치할 수 있습니다.

반대로 보안에 민감한 신호에 대한 권한은 모든 VM에 하드코딩되어야 합니다. 보안에 민감한 서비스를 새 VM에 도입하려면 VM 수준 권한 시스템을 전체적으로 업데이트해야 한다는 단점이 있습니다. 따라서 메시 내의 모든 VM을 업데이트해야 합니다.

결론

AAOS SDV는 설계에 의한 보안 접근 방식을 통해 특정 자동차 요구사항을 해결하도록 Android의 보안 아키텍처를 확장합니다. 도메인 격리를 위해 가상화를 활용하고 '기본적으로 거부' 액세스 정책을 적용하여 플랫폼은 소프트웨어 정의 차량을 위한 탄력적인 환경을 구축합니다. 암호화 무결성은 실행된 코드의 하드웨어 강제 실시간 확인을 통해 유지됩니다.

이 플랫폼은 사전 예방적 취약점 관리부터 DICE를 통한 하드웨어 기반 ID 확인에 이르기까지 지속적인 보안 수명 주기를 통합합니다. 이러한 다층적 방어를 통해 OEM은 고급 기능 업데이트 가능성과 현대 자동차 환경에 필요한 강력한 보안의 균형을 맞출 수 있습니다. 기술 사양 및 구현 세부정보는 AAOS SDV 개요 페이지에서 확인할 수 있습니다.