Considerazioni
Per garantire l'integrità di Conferma protetta Android, devono essere prese in considerazione le seguenti considerazioni. Se queste considerazioni non possono essere affrontate in modo soddisfacente, la conferma protetta non può essere implementata sul dispositivo.
Considerazioni sul kernel Linux
La conferma protetta è progettata per funzionare in modo sicuro anche se il kernel del dispositivo è compromesso. Quando la finestra di dialogo di conferma protetta è attiva, il kernel non può interferire con l'integrità dei contenuti dello schermo, l'integrità dell'input dell'utente e l'atomicità tra input e output dell'utente. Dal punto di vista dell'architettura, è necessario impedire al kernel di modificare la decisione dell'utente e di falsificare gli eventi utente. Il kernel non è considerato attendibile per questo caso d'uso, in quanto potrebbe essere sotto il controllo di un malintenzionato o sostituito con qualcosa di completamente diverso.
Considerazioni sul firmware
La conferma protetta può essere implementata su un dispositivo solo se tutti i componenti coinvolti hanno un firmware attendibile. La conferma protetta è progettata per garantire all'utente la possibilità di leggere un messaggio visualizzato nell'interfaccia utente attendibile per prendere una decisione consapevole sull'opportunità o meno di procedere con una transazione. Il driver del pannello di visualizzazione è particolarmente importante in quanto potrebbe impedire all'utente di visualizzare l'interfaccia utente attendibile.
Considerazioni sugli input
Scegli un metodo di immissione sicuro per assicurarti che gli eventi di immissione generati da questo metodo di immissione scelto non vengano trasmessi alla finestra di dialogo di conferma protetta, a meno che l'utente non generi l'evento mentre la finestra di dialogo è attiva.
Hardware fisico
Qualsiasi componente che può essere controllato dal kernel di Android, come il sistema on chip (SoC) o il circuito integrato di gestione dell'alimentazione (PMIC), non deve essere in grado di alimentare un cavo collegato a un pulsante di conferma fisico.
Considerazioni sul controller touch
La conferma protetta può utilizzare i pulsanti software sullo schermo come input. Ogni volta che il controller touch viene azionato dal TEE, devono essere adottate misure per disinfettare il suo stato.
Comportamento previsto
Interruzioni
Se il sistema interrompe la sessione di conferma a causa di una chiamata in arrivo o di un evento di alimentazione, l'HAL deve segnalare ResponseCode::Aborted. Le app ricevono il onCanceled()
callback e sanno che l'utente non ha scelto un'azione. Gli allarmi non devono interrompere la sessione, ma devono avvisare l'utente. Non sono consentiti overlay di notifica di alcun tipo mentre la finestra di dialogo è attiva.
Periodo di tolleranza per l'input
Dopo l'avvio della conferma protetta, l'input deve rimanere inattivo per almeno 1 secondo prima di diventare sensibile all'interazione dell'utente. Questo periodo di tolleranza garantisce all'utente la possibilità di reagire a una finestra di dialogo di conferma inesperada. Questo periodo di tolleranza deve essere applicato dall'app attendibile.
Rotazione dello schermo
La modalità Ritratto è l'unica obbligatoria e la rotazione dello schermo non è supportata. La rotazione dello schermo consente potenziali abusi su un sistema compromesso, ad esempio il posizionamento ingannevole dei pulsanti o la manipolazione del testo del corpo.
Errori di rendering del testo del corpo
Esiste un limite obbligatorio di 6144 (0x1800) byte per il testo del corpo, inclusi i dati extra non visualizzati e le informazioni dell'intestazione CBOR.
Inoltre, è necessario applicare un confine flessibile. Se il messaggio visualizzato non si adatta completamente allo spazio sullo schermo disponibile, assicurati che la conferma protetta venga interrotta e la transazione annullata.
Se MessageSize supera le dimensioni massime consentite, la tua implementazione deve restituire UIErrorMessageTooLong su promptUserConfirmation.
La best practice è formattare il testo del corpo dopo aver ricevuto la chiamata API. Il testo del corpo deve essere mostrato all'utente per intero.
Display secondari
I display secondari sono supportati a determinate condizioni. L'integrità dell'output e dell'input utente deve essere mantenuta e non è possibile visualizzare informazioni fuorvianti tramite altri mezzi. In caso contrario, la finestra di dialogo potrebbe essere visualizzata solo sul display principale e tutti gli altri display dovrebbero essere disattivati o vuoti. Le soluzioni di streaming e condivisione dello schermo non sono autorizzate a visualizzare la finestra di dialogo o generare conferme.