[Magisk] pndwal:
You do make it sound simple! :)

,,, But, as John Wu said, it is, unfortunately, anything but, what with hardware backed keymaster authorizations, cryptographic key storage, etc, etc.

These includeVerifiedBootState, which returns the following values:

-Verified

Indicates a full chain of trust extending from the bootloader to verified partitions, including the bootloader, boot partition, and all verified partitions.

In this state, the verifiedBootKey value is the hash of the embedded certificate, meaning the unchangeable certificate burned into ROM.

-SelfSigned

Indicates the boot partition has been verified using the embedded certificate, and the signature is valid. The bootloader displays a warning and the fingerprint of the public key before allowing the boot process to continue.

In this state, the verifiedBootKey value is the hash of the self-signing certificate.

-Unverified

Indicates a device may be freely modified. Device integrity is left to the user to verify out-of-band. The bootloader displays a warning to the user before allowing the boot process to continue.

In this state the verifiedBootKey value is empty.

-Failed

Indicates the device has failed verification. No attestation certificate actually contains this value, because in this state the bootloader halts. It's included here for completeness.

Similarly, SecurityLevel returns the following values:

-Software

The code that creates or manages the relevant element (attestation or key) is implemented in the Android system and could be altered if that system is compromised.

-TrustedEnvironment

The code that creates or manages the relevant element (attestation or key) is implemented in a Trusted Execution Environment (TEE). It could be altered if the TEE is compromised, but the TEE is highly resistant to remote compromise and moderately resistant to compromise by direct hardware attack.

-StrongBox

The code that creates or manages the relevant element (attestation or key) is implemented in a dedicated hardware security module. It could be altered if the hardware security module is compromised, but it is highly resistant to remote compromise and highly resistant to compromise by direct hardware attack.

Also, support for ID attestation for devices with Keymaster 3 which allows the device to provide proof of its hardware identifiers, such as serial number or IMEI.

ID attestation works by creating copies of the device's hardware identifiers that only the Trusted Execution Environment (TEE) can access before the device leaves the factory. A user may unlock the device's bootloader and change the system software and the identifiers reported by the Android frameworks. The copies of the identifiers held by the TEE cannot be manipulated in this way, ensuring that device ID attestation will only ever attest to the device's original hardware identifiers thereby thwarting spoofing...

...The storage is tamper-evident: If the content of the storage has been modified, the TEE treats it the same as if the copies of the content had been destroyed and refuses all ID attestation attempts. This is implemented by signing or MACing the storage...

As the article cited begins. "When hardware-backed (cryptographic) key storage is available and used, key material is more secure against extraction from the device, and Keymaster enforces restrictions that are difficult to subvert"

https://source.android.com/security/keystore/attestation :( PW