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

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

기반: 도메인 격리

공동 호스팅된 인스턴스를 격리하는 가상화

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

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

상속된 Android 보안

AAOS SDV는 개인 정보 보호 가상 머신 (pVM)에 최적화된 최소한의 Android 버전인 Microdroid에서 발전했습니다. 이 계보를 통해 Android 플랫폼 엔지니어는 이미 알고 있는 보안 기능을 설정할 수 있습니다.

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

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

검증된 취약점 관리

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

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

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

인증된 소프트웨어 배포

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

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

1. 변경 불가 스토리지

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

2. 암호화 무결성

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

3. 엄격한 격리

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

4. 원자적 복구

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

복원력: 메모리 안전 개발

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

Rust를 기본 언어로 사용

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

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

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

기기 및 메시 프로비저닝

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

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

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

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

호스트 ID를 현실에 기반

DICE (기기 식별자 구성 엔진)의 황금률: 펌웨어의 단일 코드 줄이 변경되면 (사소한 업데이트 또는 악성 익스플로잇) 파생된 복합 기기 식별자 (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 개요 페이지에서 확인할 수 있습니다.