4092a77774
status after registering it with `CHECK_EQ` macro. Bug: b/205760172 Test: atest VtsHalConfirmationUITargetTest Change-Id: I00f5a09ca525e3abb63a5d1f404fb6f3daed9442 |
||
---|---|---|
.. | ||
fuzz | ||
include | ||
.clang-format | ||
Android.bp | ||
android.hardware.confirmationui-service.trusty.rc | ||
android.hardware.confirmationui-service.trusty.xml | ||
NotSoSecureInput.cpp | ||
README | ||
service.cpp | ||
TrustyApp.cpp | ||
TrustyApp.h | ||
TrustyConfirmationUI.cpp | ||
TrustyConfirmationUI.h |
## Secure UI Architecture To implement confirmationui a secure UI architecture is required. This entails a way to display the confirmation dialog driven by a reduced trusted computing base, typically a trusted execution environment (TEE), without having to rely on Linux and the Android system for integrity and authenticity of input events. This implementation provides neither. But it provides most of the functionlity required to run a full Android Protected Confirmation feature when integrated into a secure UI architecture. ## Secure input (NotSoSecureInput) This implementation does not provide any security guaranties. The input method (NotSoSecureInput) runs a cryptographic protocols that is sufficiently secure IFF the end point is implemented on a trustworthy secure input device. But since the endpoint is currently in the HAL service itself this implementation is not secure. NOTE that a secure input device end point needs a good source of entropy for generating nonces. The current implementation (NotSoSecureInput.cpp#generateNonce) uses a constant nonce.