[[["容易理解","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 (世界標準時間)。"],[],[],null,["# Protected confirmation implementation\n\n| **Key Point:** Protected Confirmation provides a guarantee that the user has read and confirmed a transaction. This guarantee relies on proper implementation. The considerations described in this section help to ensure a secure implementation. Review the device architecture with respect to these guarantees, even under the premise that the bootloader may be unlocked and a custom Android image installed.\n\nConsiderations\n--------------\n\nThe following considerations must be addressed to ensure the integrity of\nAndroid Protected Confirmation. If these considerations can't be satisfactorily\naddressed, Protected Confirmation can't be implemented on the device.\n\n### Linux kernel considerations\n\nProtected Confirmation is designed to operate securely even if the device's\nkernel is compromised. While the Protected Confirmation dialog is active, the\nkernel can't interfere with the integrity of the screen content, the integrity\nof the user's input, and the atomicity between user input and output.\nArchitecturally, the kernel must be prevented from augmenting the user's\ndecision and from spoofing user events in the first place. The kernel isn't\nconsidered trustworthy for this use case, as it could be under the control of an\nattacker or replaced with something completely different.\n\n### Firmware considerations\n\nProtected Confirmation can be implemented on a device only if all of the\ncomponents involved have trusted firmware. Protected Confirmation is designed to\nensure that the user has a chance to read a message displayed in the Trusted UI\nto make an informed decision whether or not to proceed with a transaction. The\ndisplay panel driver is especially important as this could prevent the user from\nbeing able to view the Trusted UI.\n\n### Input considerations\n\nChoose a secure input method to ensure that input events generated by this\nchosen input method aren't conveyed to the Protected Confirmation dialog unless\nthe user generates the event while that dialog is active.\n\n#### Physical hardware\n\nAny component that can be controlled by the Android kernel, such as the\nsystem on chip (SoC) or power management integrated circuit (PMIC), must not be\nable to drive a wire connected to a physical confirmation button.\n\n#### Touch controller considerations\n\nProtected Confirmation can use on-screen software buttons as input. Anytime\nthe touch controller is being driven by the TEE, measures must be taken to\nsanitize the touch controller's state.\n| **Note:** The availability of this feature isn't guaranteed. That is, a compromised Android System or Android Kernel may block the dialog. In this case, a confirmation token must not be issued.\n\nExpected behavior\n-----------------\n\n### Interruptions\n\nIf the system interrupts the confirmation session because of an incoming\nphone call or power event, the HAL must report\n`ResponseCode::Aborted`. Apps get the `onCanceled()`\ncallback and know the user didn't choose an action. Alarms don't need to abort\nthe session but do need to notify the user. Notification overlays of any kind\naren't allowed while the dialog is active.\n\n### Input grace period\n\nAfter Protected Confirmation is initiated, the input needs to remain inactive\nfor a minimum of 1 second before it becomes responsive to user interaction. This\ngrace period ensures that the user has a chance to react to an unexpected\nconfirmation dialog. This grace period must be enforced by the trusted app.\n\n### Screen rotation\n\nPortrait is the only mandated mode, and screen rotation isn't supported.\nScreen rotation allows the potential for abuse on a compromised system, such as\nmisleading button placement or body text manipulation.\n\n### Body text rendering failures\n\nThere's a [hard\nboundary of 6144 (0x1800) bytes](/reference/hidl/android/hardware/confirmationui/1.0/types#messagesize) for the body text including extra\nnondisplayed data and CBOR header information.\nIn addition, there's a soft boundary that must be enforced. If the\nrendered message doesn't completely fit in the available screen space,\nensure that Protected Confirmation aborts and the transaction is canceled.\nIf `MessageSize` exceeds the maximum allowable size, your\nimplementation must return `UIErrorMessageTooLong` on\n`promptUserConfirmation`.\n\nBest practice is to format the body text after receiving the API call. The\nbody text must be shown to the user in full.\n\n### Secondary displays\n\nSecondary displays are supported under certain conditions. The integrity of\noutput and user input must be maintained, and no misleading information can be\ndisplayed through other means. Otherwise, the dialog may only be displayed on\nthe primary display and all other displays should be deactivated or blank.\nStreaming and screen-sharing solutions aren't allowed to display the dialog or\ngenerate confirmations."]]
