Considerazioni
È necessario prendere in considerazione le seguenti considerazioni per garantire l'integrità di Android Protected Conferma. Se queste considerazioni non possono essere affrontate in modo soddisfacente, la conferma protetta non può essere implementata nel dispositivo.
Considerazioni sul kernel Linux
La conferma protetta è progettata per funzionare in modo sicuro anche se il kernel del dispositivo è compromesso. Mentre la finestra di dialogo Conferma protetta è attiva, il kernel non può interferire con l'integrità del contenuto dello schermo, l'integrità dell'input dell'utente e l'atomicità tra input e output dell'utente. Dal punto di vista architettonico, è necessario innanzitutto impedire al kernel di potenziare la decisione dell'utente e di falsificare gli eventi dell'utente. Il kernel non è considerato affidabile per questo caso d'uso, poiché potrebbe essere sotto il controllo di un utente 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 dispongono di firmware attendibile. La Conferma protetta è progettata per garantire che l'utente abbia la possibilità di leggere un messaggio visualizzato nell'interfaccia utente attendibile per prendere una decisione informata se procedere o meno con una transazione. Il driver del pannello dello schermo è particolarmente importante poiché potrebbe impedire all'utente di visualizzare l'interfaccia utente attendibile.
Considerazioni sugli input
Scegli un metodo di input sicuro per garantire che gli eventi di input generati da questo metodo di input scelto non vengano trasmessi alla finestra di dialogo 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 Android, come il system on chip (SoC) o il circuito integrato di gestione dell'alimentazione (PMIC), non deve essere in grado di pilotare un filo collegato a un pulsante fisico di conferma.
Considerazioni sul controller touch
La Conferma protetta può utilizzare i pulsanti software sullo schermo come input. Ogni volta che il controller touch viene guidato dal TEE, è necessario adottare misure per disinfettare lo stato del controller touch.
Comportamento atteso
Interruzioni
Se il sistema interrompe la sessione di conferma a causa di una telefonata in arrivo o di un evento di alimentazione, l'HAL deve segnalare ResponseCode::Aborted . Le app ricevono la richiamata onCanceled() e sanno che l'utente non ha scelto un'azione. Non è necessario che gli allarmi interrompano la sessione ma devono avvisare l'utente. Non sono consentiti sovrapposizioni di notifiche di alcun tipo mentre la finestra di dialogo è attiva.
Inserisci il periodo di grazia
Dopo l'avvio della conferma protetta, l'input deve rimanere inattivo per almeno 1 secondo prima che possa rispondere all'interazione dell'utente. Questo periodo di grazia garantisce che l'utente abbia la possibilità di reagire a una finestra di dialogo di conferma imprevista. Questo periodo di grazia deve essere applicato dall'app attendibile.
Rotazione dello schermo
La modalità verticale è l'unica modalità obbligatoria e la rotazione dello schermo non è supportata. La rotazione dello schermo consente potenziali abusi su un sistema compromesso, come il posizionamento fuorviante dei pulsanti o la manipolazione del corpo del testo.
Errori di rendering del corpo del testo
Esiste un limite rigido di 6144 (0x1800) byte per il corpo del testo, inclusi dati extra non visualizzati e informazioni sull'intestazione CBOR. Inoltre, c'è un confine morbido che deve essere applicato. Se il messaggio visualizzato non rientra completamente nello spazio disponibile sullo schermo, assicurati che la Conferma protetta venga interrotta e la transazione venga annullata. Se MessageSize supera la dimensione massima consentita, l'implementazione deve restituire UIErrorMessageTooLong su promptUserConfirmation .
La procedura migliore consiste nel formattare il corpo del testo dopo aver ricevuto la chiamata API. Il corpo del testo deve essere mostrato all'utente per intero.
Display secondari
I display secondari sono supportati in determinate condizioni. L'integrità dell'output e dell'input dell'utente deve essere mantenuta e nessuna informazione fuorviante può essere visualizzata con 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.