Android 보안 확인의 무결성을 보장하려면 다음 고려사항을 해결해야 합니다. 이러한 고려사항이 만족스럽게 해결되지 않으면 기기에서 보안 확인을 구현할 수 없습니다.
Linux 커널 고려사항
보안 확인은 기기의 커널이 손상된 경우에도 안전하게 작동하도록 설계되었습니다. 보안 확인 대화상자가 활성화되어있는 동안 커널은 화면 콘텐츠의 무결성, 사용자 입력의 무결성, 사용자 입력과 출력 간의 원자성을 간섭할 수 없습니다.
무엇보다 커널은 구조적으로 사용자의 결정을 보강하고 사용자 이벤트를 위장하지 않아야 합니다. 이와 같은 경우에는 커널이 공격자에 의해 제어되거나 완전히 다른 무언가로 대체될 수 있으므로 신뢰할 수 있다고 간주되지 않습니다.
펌웨어 고려사항
관련된 모든 구성요소에 신뢰할 수 있는 펌웨어가 있는 경우에만 기기에서 보안 확인을 구현할 수 있습니다. 보안 확인은 사용자가 신뢰할 수 있는 UI에 표시된 메시지를 읽고 거래를 진행할지 여부를 결정할 수 있도록 만들어졌습니다. 이때 사용자가 신뢰할 수 있는 UI를 볼 수 없게 될 수 있으므로 디스플레이 패널 드라이버가 특히 중요합니다.
입력 고려사항
보안 입력 방법을 선택하여, 대화상자가 활성 상태인 동안 사용자가 이벤트를 생성한 경우가 아니면 선택된 입력 방법에 의해 생성된 입력 이벤트가 보안 확인 대화상자로 전달되지 않도록 합니다.
물리적 하드웨어
단일 칩 시스템(SoC) 또는 전원 관리 집적 회로(PMIC)와 같이 Android 커널에서 제어할 수 있는 모든 구성요소는 물리적 확인 버튼에 연결된 와이어를 구동할 수 없어야 합니다.
터치 컨트롤러 고려사항
보안 확인에서는 화면상의 소프트웨어 버튼을 입력으로 사용할 수 있습니다. 터치 컨트롤러가 TEE에 의해 구동될 때마다 터치 컨트롤러의 상태를 처리하기 위한 조치를 취해야 합니다.
예상 동작
중단
수신 전화나 전원 이벤트로 인해 시스템에서 확인 세션을 중단하는 경우 HAL에서 ResponseCode::Aborted를 보고해야 합니다. 앱에서는 onCanceled() 콜백을 가져오고 사용자가 작업을 선택하지 않았다고 확인합니다. 알람은 세션을 취소하지 않아도 되지만 사용자에게는 알려야 합니다. 대화상자가 활성화되어 있는 동안에는 어떤 유형의 알림 오버레이도 허용되지 않습니다.
입력 유예 기간
보안 확인이 시작된 후에는 사용자 상호작용에 응답하기 전에 입력이 최소 1초 동안 비활성 상태로 유지되어야 합니다. 이 유예 기간을 통해 사용자는 예기치 않은 확인 대화상자에 반응할 수 있습니다. 이 유예 기간은 신뢰할 수 있는 앱에서 시행되어야 합니다.
화면 회전
세로 모드만이 필수 모드이며 화면 회전은 지원되지 않습니다.
화면 회전을 허용하면 오해의 소지가 있는 버튼 위치 또는 본문 텍스트 조작과 같이 손상된 시스템에서 악용될 가능성이 있습니다.
본문 텍스트 렌더링 실패
표시되지 않는 추가 데이터 및 CBOR 헤더 정보를 포함하여 본문 텍스트에는 6144(0x1800)바이트의 하드 경계가 있습니다.
또한 적용되어야 하는 소프트 경계도 있습니다. 렌더링된 메시지가 사용 가능한 화면 공간에 완전히 맞지 않는다면 보안 확인 및 거래가 취소되었는지 확인하세요.
MessageSize가 허용되는 최대 크기를 초과하는 경우 구현에서는 promptUserConfirmation에서 UIErrorMessageTooLong을 반환해야 합니다.
가장 좋은 방법은 API 호출을 받은 후에 본문 텍스트의 서식을 지정하는 것입니다. 본문 텍스트 전체가 사용자에게 표시되어야 합니다.
보조 디스플레이
보조 디스플레이는 특정 조건 내에서 지원됩니다. 출력과 사용자 입력의 무결성이 유지되어야 하고 다른 수단을 통해 오해의 소지가 있는 정보를 표시하면 안 됩니다. 이 조건을 충족하지 않으면 대화상자가 기본 디스플레이에만 표시될 수 있으며 다른 모든 디스플레이는 비활성화되거나 아무 내용도 표시되지 않습니다.
스트리밍 및 화면 공유 솔루션으로는 대화상자를 표시하거나 확인을 생성할 수 없습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# 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."]]