사용 사례

이 문서에는 AVF의 일반적인 사용 사례가 포함되어 있습니다.

격리된 컴파일

보호된 VM은 소프트웨어 보안 인클레이브로서 보안에 민감한 코드를 컴파일할 수 있는 안전한 환경을 제공합니다. 이 환경을 사용하면 bootclasspath 및 시스템 서버 JAR의 컴파일(APEX 업데이트에 의해 트리거됨)을 초기 부팅에서 재부팅 전으로 이동할 수 있으며 APEX 업데이트 후 부팅 시간이 크게 줄어듭니다.

구현은 com.android.compos APEX에 있습니다. 이 구성요소는 선택사항이며 makefile을 사용하여 포함할 수 있습니다.

격리된 컴파일

그림 1. 메인라인 업데이트에서 JAR 컴파일

보안 목표는 확인된 입력을 실제로 컴파일하고 출력을 입력과 격리하여 생성하는 것입니다. 신뢰할 수 없는 클라이언트로서 Android는 (Android가 부팅 시간 컴파일로 대체되는 경우) 실패를 일으키지 않고 컴파일 출력을 변경할 수 있는 방법이 없습니다.

VM의 컴파일 서비스는 전체 컴파일 중에 오류가 없는 경우에만 서명을 생성합니다. Android는 서명 확인을 위해 VM에서 공개 키를 가져올 수 있습니다.

VM의 키는 다른 VM 매개변수(예: 디버깅 가능 여부)와 함께 VM의 DICE 프로필에서 생성되며 이 프로필은 VM에 마운트된 APEX 및 APK에서 정의합니다.

공개 키가 예기치 않은 VM에서 비롯되지 않았는지 확인하기 위해 Android는 VM을 부팅하여 키가 올바른지 확인합니다. 각 APEX 업데이트 후 초기 부팅 시 VM이 부팅됩니다.

보호된 VM의 자체 검사 부팅을 사용하면 컴파일 서비스가 확인된 코드만 실행합니다. 따라서 코드는 특정 조건을 충족하는 입력만 허용하도록 결정할 수 있습니다. 예를 들어 허용 목록에 이름과 fs-verity 다이제스트가 정의된 경우에만 입력 파일을 허용할 수 있습니다.

VM에서 노출된 모든 API는 공격에 노출되는 영역에 있습니다. 모든 입력 파일과 매개변수는 신뢰할 수 없는 클라이언트에서 비롯된 것으로 간주되며 처리 전에 확인 및 검증되어야 합니다.

입력/출력 파일 무결성은 파일이 신뢰할 수 없는 파일 서버로서의 Android에 저장된 상태에서 다음과 같이 VM이 확인합니다.

  • fs-verity 알고리즘을 사용하여 파일을 사용하기 전에 입력 파일의 콘텐츠를 확인해야 합니다. 입력 파일을 VM에서 사용할 수 있으려면 VM의 DICE 프로필에 사용되는 컨테이너(APK)에 루트 해시를 제공해야 합니다. 신뢰할 수 있는 루트 해시를 사용하면 공격자가 감지되지 않은 상태에서 입력을 조작할 수 없습니다.
  • 출력 파일의 무결성은 VM에서 유지되어야 합니다. 출력 파일이 Android에 저장되더라도 생성 중에는 무결성이 동일한 fs-verity 트리 형식으로 유지되지만 동적으로 업데이트될 수 있습니다. 최종 출력 파일은 VM에서 격리된 루트 해시로 식별할 수 있습니다. VM의 서비스는 서명으로 출력 파일을 보호합니다.