2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
부팅 확인
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
자체 검사 부팅을 사용하려면 사용 전에 부팅되는 Android 버전에 포함된 모든 실행 코드 및 데이터를 암호화 방식으로 확인해야 합니다. 여기에는 커널(boot
파티션에서 로드), 기기 트리(dtbo
파티션에서 로드), system
파티션, vendor
파티션 등이 포함됩니다.
한 번만 읽히는 boot
및 dtbo
와 같은 작은 파티션은 일반적으로 콘텐츠 전체를 메모리에 로드한 후 해시를 계산하여 확인됩니다. 그런 다음, 계산된 이 해시 값은 예상된 해시 값과 비교됩니다. 값이 일치하지 않으면 Android가 로드되지 않습니다.
자세한 내용은 부팅 흐름을 참조하세요.
메모리에 맞지 않는 더 큰 파티션(예: 파일 시스템)은 해시 트리를 사용할 수 있습니다. 이 해시 트리에서 인증은 데이터가 메모리에 로드될 때 발생하는 연속 프로세스입니다. 이때 해시 트리의 루트 해시는 런타임 과정에서 계산되며 예상 루트 해시 값과 대조하여 확인됩니다.
Android에는 더 큰 파티션을 확인하기 위해 dm-verity 드라이버가 포함되어 있습니다. 어느 시점에 계산된 루트 해시가 예상 루트 해시 값과 일치하지 않으면 데이터가 사용되지 않고 Android가 오류 상태가 됩니다. 자세한 내용은 dm-verity 손상을 참조하세요.
예상 해시는 일반적으로 전용 파티션의 확인된 각 파티션 끝 또는 시작 부분이나 둘 다에 저장됩니다. 결정적으로 이러한 해시는 신뢰할 수 있는 루트에 의해 직접 또는 간접적으로 서명됩니다. 예를 들어 AVB 구현은 두 가지 방법을 모두 지원합니다. 자세한 내용은 Android 자체 검사 부팅을 참조하세요.
롤백 보호
완전히 안전한 업데이트 프로세스를 사용하더라도 비지속적인 Android 커널 취약점 공격이 더 취약한 이전 버전의 Android를 수동으로 설치하고 취약한 버전으로 재부팅한 후 이 Android 버전을 사용하여 지속적인 취약점 공격 코드를 설치할 수 있습니다. 이를 통해 공격자는 영구적으로 기기를 소유하고 업데이트 사용 중지를 비롯하여 어떤 작업이든 할 수 있습니다.
이러한 종류의 공격으로부터의 보호를 롤백 보호라고 합니다. 롤백 보호는 일반적으로 변조 탐지 가능 저장소를 사용하여 최신 버전의 Android를 기록하고 Android 버전이 기록된 버전보다 낮으면 부팅을 거부함으로써 구현됩니다. 일반적으로 버전은 파티션별로 추적됩니다.
AVB에서 롤백 보호를 처리하는 방법에 관한 자세한 내용은 AVB README를 참조하세요.
인증 오류 처리
부팅 시(예를 들어 boot
파티션의 계산된 해시가 예상 해시와 일치하지 않으면) 또는 런타임 시(예를 들어 system
파티션의 dm-verity에서 인증 오류가 발생하면) 인증이 실패할 수 있습니다. 부팅 시 인증이 실패하면 기기를 부팅할 수 없으며 최종 사용자는 기기 복구 단계를 실행해야 합니다.
런타임 시 인증이 실패하면 흐름이 조금 더 복잡합니다. 기기가 dm-verity를 사용한다면 기기를 restart
모드에서 구성해야 합니다. restart
모드에서 인증 오류가 발생하면 기기가 이유를 표시하도록 특정 플래그가 설정된 상태로 즉시 다시 시작됩니다. 부트로더는 이 플래그를 확인하고 I/O 오류(eio
) 모드를 사용하도록 dm-verity를 전환하며 새 업데이트가 설치될 때까지 이 모드를 유지해야 합니다.
eio
모드로 부팅할 때 기기에 손상이 감지되어 기기가 올바르게 작동하지 않을 수 있음을 사용자에게 알리는 오류 화면이 표시됩니다. 사용자가 화면을 닫을 때까지 이 화면이 표시됩니다. eio
모드에서는 인증 오류가 발생하면 dm-verity 드라이버가 기기를 다시 시작하지 않으며 대신 EIO 오류가 반환되고 앱에서 오류를 처리해야 합니다.
의도는 시스템 업데이터가 실행되거나(따라서 손상 오류가 없는 새로운 OS가 설치될 수 있음) 사용자가 기기에서 가능한 많은 데이터를 얻을 수 있게 하기 위한 것입니다. 새 OS가 설치되면 부트로더는 새로 설치된 OS를 인식하고 restart
모드로 다시 전환합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(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"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Verify Boot\n\nVerified Boot requires cryptographically verifying all executable code and data\nthat is part of the Android version being booted before it is used. This includes\nthe kernel (loaded from the `boot` partition), the device tree (loaded\nfrom the `dtbo` partition), `system` partition,\n`vendor` partition, and so on.\n\n\nSmall partitions, such as `boot` and `dtbo`, that are read\nonly once are typically verified by loading the entire contents into memory and\nthen calculating its hash. This calculated hash value is then compared to the\n*expected hash value* . If the value doesn't match, Android won't load.\nFor more details, see [Boot Flow](/docs/security/features/verifiedboot/boot-flow).\n\n\nLarger partitions that won't fit into memory (such as, file systems) may use\na hash tree where verification is a continuous process happening as data is\nloaded into memory. In this case, the root hash of the hash tree is calculated\nduring run time and is checked against the *expected root hash value* .\nAndroid includes the [dm-verity\ndriver](/docs/security/features/verifiedboot/dm-verity) to verify larger partitions. If at some point the calculated root\nhash doesn't match the *expected root hash value* , the data isn't used\nand Android enters an error state. For more details, see\n[dm-verity\ncorruption](/docs/security/features/verifiedboot/boot-flow#dm-verity-corruption).\n\n\nThe *expected hashes* are typically stored at either the end or beginning\nof each verified partition, in a dedicated partition, or both. Crucially, these\nhashes are signed (either directly or indirectly) by the root of trust. As an\nexample, the AVB implementation supports both approaches, see\n[Android Verified Boot](/docs/security/features/verifiedboot/avb) for details.\n\nRollback protection\n-------------------\n\n\nEven with a completely secure update process, it's possible for a non-persistent\nAndroid kernel exploit to manually install an older, more vulnerable version of\nAndroid, reboot into the vulnerable version, and then use that Android version to\ninstall a persistent exploit. From there the attacker permanently owns the device\nand can do anything, including disabling updates.\n\n\nThe protection against this class of attacks is called *Rollback\nProtection*. Rollback protection is typically implemented by using\ntamper-evident storage to record the most recent version of the Android and\nrefusing to boot Android if it's lower than the recorded version. Versions\nare typically tracked on a per-partition basis.\n\n\nFor more details on how AVB handles rollback protections, see the AVB\n[README](https://android.googlesource.com/platform/external/avb/+/android16-release/README.md#Rollback-Protection).\n\nHandle verification errors\n--------------------------\n\n\nVerification can fail either at boot time (such as, if the calculated hash on\n`boot` partition doesn't match the expected hash) or at run time\n(such as, if dm-verity encounters a verification error on the\n`system` partition). If verification fails at boot time, the device\ncan't boot and the end user needs to go through steps to recover the device.\n\n\nIf verification fails at run-time the flow is a bit more complicated. If the\ndevice uses dm-verity, it should be configured in `restart` mode. In\n`restart` mode, if a verification error is encountered, the device is\nimmediately restarted with a specific flag set to indicate the reason. The boot\nloader should notice this flag and switch dm-verity over to use I/O Error\n(`eio`) mode and stay in this mode until a new update has been\ninstalled.\n\n\nWhen booting in `eio` mode, the device shows an error screen\ninforming the user that corruption has been detected and the device might not\nfunction correctly. The screen shows until the user dismisses it. In\n`eio` mode the dm-verity driver won't restart the device if a\nverification error is encountered, instead an EIO error is returned and the\napp needs to deal with the error.\n\n\nThe intent is that either the system updater will run (so a new OS without\ncorruption errors can be installed) or the user can get as much of their data\noff the device as possible. Once the new OS has been installed, the boot loader\nnotices the newly installed OS and switches back to `restart` mode."]]