Реализация защищенного подтверждения

Соображения

Чтобы обеспечить целостность Android Protected Confirmation, необходимо принять во внимание следующие факторы. Если эти соображения не могут быть удовлетворительно учтены, защищенное подтверждение не может быть реализовано на устройстве.

Особенности ядра Linux

Защищенное подтверждение предназначено для безопасной работы, даже если ядро ​​устройства скомпрометировано. Пока активно диалоговое окно «Защищенное подтверждение», ядро ​​не может вмешиваться в целостность содержимого экрана, целостность ввода пользователя и атомарность между вводом и выводом пользователя. С архитектурной точки зрения ядро ​​не должно дополнять решение пользователя и в первую очередь подделывать пользовательские события. Ядро не считается заслуживающим доверия для этого варианта использования, так как оно может находиться под контролем злоумышленника или быть заменено чем-то совершенно другим.

Рекомендации по прошивке

Защищенное подтверждение может быть реализовано на устройстве только в том случае, если все задействованные компоненты имеют доверенную прошивку. Защищенное подтверждение предназначено для того, чтобы у пользователя была возможность прочитать сообщение, отображаемое в доверенном пользовательском интерфейсе, чтобы принять обоснованное решение о том, следует ли продолжать транзакцию. Драйвер панели дисплея особенно важен, поскольку он может помешать пользователю просматривать доверенный пользовательский интерфейс.

Входные данные

Выберите безопасный метод ввода, чтобы гарантировать, что события ввода, сгенерированные этим выбранным методом ввода, не будут передаваться в диалоговое окно защищенного подтверждения, если только пользователь не сгенерирует событие, когда это диалоговое окно активно.

Физическое оборудование

Любой компонент, которым может управлять ядро ​​Android, например система на кристалле (SoC) или интегральная схема управления питанием (PMIC), не должен управлять проводом, подключенным к физической кнопке подтверждения.

Особенности сенсорного контроллера

Защищенное подтверждение может использовать программные кнопки на экране в качестве ввода. Каждый раз, когда сенсорный контроллер управляется TEE, необходимо принимать меры для очистки состояния сенсорного контроллера.

Ожидаемое поведение

Прерывания

Если система прерывает сеанс подтверждения из-за входящего телефонного звонка или события питания, HAL должен сообщить ResponseCode::Aborted . Приложения получают обратный вызов onCanceled() и знают, что пользователь не выбрал действие. Аварийные сигналы не должны прерывать сеанс, но должны уведомлять пользователя. Наложения уведомлений любого типа не допускаются, пока диалоговое окно активно.

Введите льготный период

После инициирования защищенного подтверждения ввод должен оставаться неактивным в течение как минимум 1 секунды, прежде чем он станет реагировать на действия пользователя. Этот льготный период гарантирует, что у пользователя будет возможность отреагировать на неожиданное диалоговое окно подтверждения. Этот льготный период должен применяться доверенным приложением.

Поворот экрана

Портрет — единственный обязательный режим, а поворот экрана не поддерживается. Поворот экрана допускает возможность злоупотреблений в скомпрометированной системе, таких как вводящее в заблуждение размещение кнопок или манипулирование основным текстом.

Сбои рендеринга основного текста

Существует жесткая граница в 6144 (0x1800) байтов для основного текста, включая дополнительные неотображаемые данные и информацию заголовка CBOR. Кроме того, существует мягкая граница, которую необходимо соблюдать. Если отображаемое сообщение не полностью помещается на доступном пространстве экрана, убедитесь, что защищенное подтверждение прерывается и транзакция отменяется. Если MessageSize превышает максимально допустимый размер, ваша реализация должна вернуть UIErrorMessageTooLong в promptUserConfirmation .

Лучшей практикой является форматирование основного текста после получения вызова API. Основной текст должен быть показан пользователю полностью.

Дополнительные дисплеи

Вторичные дисплеи поддерживаются при определенных условиях. Должна поддерживаться целостность вывода и ввода пользователя, и никакая вводящая в заблуждение информация не может отображаться другими средствами. В противном случае диалоговое окно может отображаться только на основном дисплее, а все остальные дисплеи должны быть деактивированы или пусты. Решениям для потоковой передачи и совместного использования экрана не разрешается отображать диалоговое окно или генерировать подтверждения.