2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
개발자 옵션 보호
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android 호환성 정의 문서에 따라 OEM은 앱 개발을 사용 설정하는 방법을 제공해야 합니다. 그러나 차량 내 개발자 옵션을 모바일과 유사하게 제공하면 차량이 공격에 취약하게 됩니다. 이제 OEM은 인증된 암호화 토큰 메커니즘을 사용하여 개발자 옵션 액세스를 제어할 수 있습니다.
특히 OEM은 다음과 같은 작업을 할 수 있습니다.
- 최초 부팅 전에 원하는 기본 제한을 설정할 수 있습니다.
- 원하는 경우 암호화 토큰으로 개발자를 안전하게 승인할 수 있습니다.
- 개발자가 인증되고 동시에 승인되면 제한 변경사항을 적용할 수 있습니다.
이 문서에서는 디버깅 제한 컨트롤러 앱과 원격 토큰 발급기관 엔드포인트로 구성된 참조 구현에 관해 설명합니다.
용어
이 문서에는 용어 외에 다음과 같은 명칭이 사용됩니다.
- RFC 7515에 정의된 JWS(JSON Web Signature)
- 미국 국립 표준 기술 연구소(NIST)
디자인
OEM은 JSON Web Signature(JWS) 토큰(RFC7515)을 사용하여 개발자를 승인할 수 있습니다. 참조 구현에서 액세스 토큰은 OEM에서 발급되고 제한 컨트롤러 앱에서 사용됩니다. 액세스 토큰은 재전송 공격과 위조된 토큰에 대처하도록 설계되었습니다.

그림 1. 디자인
통합 및 구성
OEM은 최초 부팅 시 원하는 기본 제한을 지정해야 합니다. 이 작업은 AOSP 프레임워크의 기본값을 재정의하기 위한 몇 가지 정적 리소스 오버레이로 진행됩니다.
헤드리스 시스템 사용자와 관련된 기본 제한은 frameworks/base/core/res/res/values/config.xml
에서 config_defaultFirstUserRestrictions
문자열로 구성할 수 있습니다. 예를 들면 다음과 같습니다.
<!-- User restrictions set when the first user is created.
Note: Also update appropriate overlay files. -->
<string-array translatable="false" name="config_defaultFirstUserRestrictions">
<item>no_debugging_features</item>
</string-array>
운전자, 승객, 손님과 관련된 기본 제한은 frameworks/base/core/res/res/xml/config_user_types.xml
에서 구성할 수 있습니다. OEM은 이러한 문자열을 오버레이하여 각 사용자 유형의 기본 제한을 각각 설정할 수 있습니다. 예를 들면 다음과 같습니다.
<user-types>
<full-type name="android.os.usertype.full.SECONDARY" >
<default-restrictions no_debugging_features="true"/>
</full-type>
<full-type name="android.os.usertype.full.GUEST" >
<default-restrictions no_debugging_features="true"/>
</full-type>
</user-types>
참조 구현은 AOSP의 다음 위치에서 제공됩니다.
packages/apps/Car/DebuggingRestrictionController
테스트
OEM은 참조 구현을 바탕으로 빌드 작업을 시작하는 것이 좋습니다.
- 오버레이 파일에서 원하는 제한을 구성한 후 AAOS를 컴파일하고 정의된 흐름을 확인합니다. 참조 앱과 로컬 JWS 지원 서비스를 사용하여 액세스 설정을 확인합니다.
- JWS 지원 클라우드 서비스를 사용하도록 시스템을 구성합니다(선택사항). 백엔드 서비스에서 원하는 흐름을 관찰하고 있는지 확인합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2024-05-01(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-05-01(UTC)"],[],[],null,["# Secure developer options\n\nPer the [Android Compatibility Definition Document](/docs/compatibility/cdd),\nOEMs must provide a way to enable app development. However, providing mobile-like\ndeveloper options within cars leaves those cars vulnerable to attack. Access to developer\noptions can now be gated by an OEM using an authenticated cryptographic token mechanism.\nSpecifically, an OEM can:\n\n- Set desired default restrictions before the first boot.\n- Securely authorize developers, with crypto tokens if preferred.\n- Apply restriction changes once a developer is both authenticated and authorized.\n\nThis article describes a reference implementation consisting of a debugging restriction\ncontroller app and a remote token issuer endpoint.\n\nTerminology\n-----------\n\nIn addition to [Terminology](/docs/automotive/start/terms),\nthese terms are used in this article:\n\n- JSON Web Signature (JWS), defined in RFC 7515\n- National Institute of Standards and Technology (NIST)\n\nDesign\n------\n\nOEMs can authorize developers with JSON Web Signature (JWS) tokens (RFC7515). In the\nreference implementation, access tokens are issued by OEMs and consumed by the restriction\ncontroller app. Access tokens are designed to resist replay attacks and forged tokens.\n\n**Figure 1.** Design\n\nIntegration and configuration\n-----------------------------\n\nOEMs must specify the desired default restrictions on the first boot. This is done with\nseveral static resource overlays to override the defaults in the AOSP framework.\n\nThe default restrictions for the headless system user can be configured with the\n`config_defaultFirstUserRestrictions` string in\n`frameworks/base/core/res/res/values/config.xml`, for example: \n\n```scdoc\n\u003c!-- User restrictions set when the first user is created.\n Note: Also update appropriate overlay files. --\u003e\n \u003cstring-array translatable=\"false\" name=\"config_defaultFirstUserRestrictions\"\u003e\n \u003citem\u003eno_debugging_features\u003c/item\u003e\n \u003c/string-array\u003e\n```\n\nThe default restrictions for drivers, passengers, and guests can be configured in\n`frameworks/base/core/res/res/xml/config_user_types.xml`. An OEM can overlay\\|\nthese strings to set the default restrictions on each type of user respectively, for example: \n\n```carbon\n\u003cuser-types\u003e\n \u003cfull-type name=\"android.os.usertype.full.SECONDARY\" \u003e\n \u003cdefault-restrictions no_debugging_features=\"true\"/\u003e\n \u003c/full-type\u003e\n \u003cfull-type name=\"android.os.usertype.full.GUEST\" \u003e\n \u003cdefault-restrictions no_debugging_features=\"true\"/\u003e\n \u003c/full-type\u003e\n\u003c/user-types\u003e\n```\n\nA reference implementation is provided at the following location in AOSP: \n\n```carbon\npackages/apps/Car/DebuggingRestrictionController\n```\n\nTesting\n-------\n\nGoogle recommends that OEMs start with the reference implementation and build out from there.\n\n1. After configuring the desired restrictions in the overlay files, compile AAOS and validate the defined flows. Use the reference app and local JWS enabled service to verify your access settings.\n2. Configure the system to use your JWS enabled cloud service (optional). Verify you're observing the desired flow on your backend service."]]