Autenticità delle informazioni visualizzate su un dispositivo non attendibile

L'idea di utilizzare lo sfondo riconoscibile è piuttosto buona. Tuttavia, T. Pornin è stato così gentile da evidenziare alcuni problemi con questo approccio.

Corto: usa MobiCore o altre implementazioni TrustZone laddove disponibili. Per i dispositivi non attendibili senza TEE, al momento è necessario utilizzare solo il sistema operativo avanzato. In futuro, forse più dispositivi offrono TEE.

Problemi con fiducia e conferma

In definitiva, il problema è il seguente: se non ti puoi fidare dei componenti e del software in esecuzione sul dispositivo, non ti puoi fidare che il dispositivo non cambi il messaggio / il pulsante di conferma mostrato all'utente.

Non esiste una soluzione perfetta per questo problema (chiedere conferma sul dispositivo non affidabile). Questo è un fatto ampiamente noto. Ci sono anche occasionalmente problemi con dispositivi generalmente considerati "affidabili" (ad esempio ATM). Quindi, le attività bancarie e creditizie si aspettano sempre una certa quantità di frodi e sono pronte a gestirle.

Dispositivi non attendibili

Per molte applicazioni, attualmente è considerato abbastanza sicuro con applicazioni che girano direttamente su dispositivi mobili non fidati. (Come ad esempio servizi bancari online ecc.)

Ambiente di esecuzione affidabile

E se fosse possibile avere un ambiente fidato per casi d'uso che necessitano di fiducia extra? (Per casi d'uso mobile commerce, BYOD, ecc.)

Gli operatori di rete e i produttori di hardware hanno formalizzato gran parte dei requisiti di Trusted Execution Environment utili per l'esecuzione di "software fidato" in un ambiente attendibile sul dispositivo che non-trusted OS (noto anche come HLOS, Rich OS, OS General Purpose o Normal World OS ). Questi documenti sono OMTP TR0 e OMTP TR1. Sono una delle migliori presentazioni dei requisiti abituali per TEE.

TrustZone

ARM + Trusted Logic ha iniziato a lavorare su questa idea circa dieci anni fa. I processori ARM hanno ottenuto TrustZone, che è presente da allora. Sebbene in gran parte una buona idea nella pratica, il problema principale era il supporto dell'hardware, ma le soluzioni software l'hanno utilizzata fino a poco tempo fa.

Tecnicamente, è possibile considerare TrustZone come supporto HW limitato per la virtualizzazione, con l'intenzione di utilizzare un sistema operativo ricco e un sistema operativo sicuro.

G & D MobiCore è stata una delle poche implementazioni che hanno raggiunto i principali telefoni cellulari, è disponibile su Samsung S3, S4. Samsung Note III ha Samsung Knox. Penso che sia anche basato su MobiCore su TrustZone.

Alcuni altri telefoni hanno qualche altro software. In molti casi, non sono disponibili dettagli su ciò che i telefoni fanno con il software che possono o caricano su TrustZone, che è disponibile su quasi tutti gli attuali smartphone.

Per ottenere il corretto supporto SW per TrustZone, G & D, ARM e Trusted Logic Mobility hanno fondato insieme Trustonic, che sta rendendo il sistema operativo Trusted di nuova generazione     

Comprendo la tua domanda come segue: esiste un dispositivo tangibile che può produrre dati e inviarli via radio (Bluetooth); e un altro dispositivo (ad esempio uno smartphone) che riceve detti dati e lo visualizza; il problema è che il secondo dispositivo non può essere considerato affidabile. Quindi la domanda è: possiamo fare qualcosa al riguardo, in modo che possiamo acquisire una certa confidenza nei dati visualizzati essendo una rappresentazione fedele di ciò che il primo dispositivo ha inviato?

In generale, no, non possiamo; bugiardi mentono. Salvo i dati inviati dal primo dispositivo vengono forniti con una sorta di checksum o firma che il secondo dispositivo non può falsificare o falsificare ( firme digitali e MAC potrebbero dimostrarsi utili strumenti di crittografia per questo), e che l'osservatore umano verifica indipendentemente dallo smartphone non protetto. Quest'ultimo punto è il vero problema: un normale osservatore umano non calcolerà nella sua testa una verifica della firma o un MAC.

Soluzioni alternative per questo tipo di situazione sono disponibili in due tipi:

• Aggiungi uno schermo direttamente sul primo dispositivo, in modo che il dispositivo possa visualizzare i suoi dati direttamente, senza interazione dallo smartphone potenzialmente ostile. Questo è ciò che viene fatto con terminali di pagamento : sebbene siano collegati a un registratore di cassa che è, in pratica, un PC, tale i terminali hanno ancora il proprio schermo e la propria tastiera perché il registratore di cassa non è considerato attendibile.

• Aggiungi un terzo dispositivo alla danza. Dare all'utente un dispositivo di cui si fida e che verificherà qualsiasi MAC o firma calcolata dal primo dispositivo. Mutatis mutandi , questo è Internet, con la mappatura degli smartphone non fidati ai semplici router; alcuni SSL tra origine e destinazione proteggono l'integrità (e la riservatezza) dei dati da maltrattamenti da parte dei router.

(Potremmo notare che questo problema è anche un problema intrinseco con le smart card inserite nel PC tramite lettori dedicati o porte USB. Quando inseriamo il codice PIN, è sul PC, non possiamo sapere davvero cosa chiede il PC smart card per firmare.)

Lo schema per sovrapporre il testo su un'immagine conosciuta è intelligente, ma non sicuro. Non fa nulla per impedire a un utente malintenzionato di aggiungere contenuti (pensa di aggiungere zero alla fine di un numero - questo potrebbe essere dannoso). Inoltre, dipende dalla segretezza dell'immagine sorgente e dalla capacità umana di distinguere parti che sono state "riempite", il che è rischioso.

La soluzione migliore sarebbe semplicemente visualizzare il messaggio normalmente insieme a un HMAC e quindi trascrivere l'intero messaggio con HMAC su un altro dispositivo per la verifica.

Se nessun altro dispositivo è disponibile, ciò che ti serve è una firma digitale che possa essere verificata da un essere umano, ma non può essere modificata da un computer senza che la persona se ne accorga. Una cosa del genere non esiste ancora. Tuttavia, qualcosa del genere potrebbe funzionare teoricamente, anche se sarebbe davvero ingombrante e non sarebbe sicuro contro la manomissione di un essere umano:

1. Crea una parola di sicurezza che sia il dispositivo sicuro sia l'umano conoscono.
2. Aggiungi la parola di sicurezza alla fine del messaggio.
3. Crea un algoritmo di checksum verificabile manualmente e calcola il checksum del messaggio. (Questo checksum non deve essere crittograficamente sicuro, quindi qualcosa come CRC32 modificato per rendere più semplice il calcolo manuale andrebbe bene.)
4. Aggiungi il checksum alla fine del messaggio
5. Scrivi l'intero messaggio utilizzando una libreria CAPTCHA in modo che un computer non possa leggerne nessuno.

Qualsiasi manomissione del messaggio interromperebbe il checksum e la sostituzione all'ingrosso rimuoverà la parola di sicurezza. La parola di sicurezza potrebbe essere copiata, ma poiché un computer non può leggere la parola, non sarebbe possibile calcolare un checksum corretto su un messaggio che lo include. Se si desidera proteggere dalla ripetizione e dal riordino dei messaggi, è possibile anche aggiungere un nonce (un contatore di messaggi monotonicamente crescente farebbe). Se ti interessa la freschezza puoi aggiungere un timestamp (prima di applicare il checksum, ovviamente).

Avviso: Il successo di questo schema hairbrained non dipende solo dalla sicurezza dei CAPTCHA (che sono stati attaccati con successo molte volte), ma dall'essere in grado di leggere l' intero messaggio senza errori. Dato che i tassi di errore umano sui CAPTCHA a una sola parola non sono banali, ciò potrebbe portare a un tasso di successo di verifica piuttosto basso, che potrebbe causare frustrazione. Lo stesso messaggio potrebbe essere scritto più volte per ridurre il tasso di errore umano, ma ciò renderebbe anche più semplice per un computer interrompere il CAPTCHA.

Gli altri hanno già coperto i dettagli tecnici. Per rispondere alla tua domanda direttamente attraverso i principi di base:

"[Dopo che qualcosa è stato trasferito dal bluetooth.] Esiste un metodo semplice ed efficace per garantire che le informazioni visualizzate non siano state alterate dal malware su quel PC o telefono ricevente?"

La risposta è no, non è possibile.

Il tuo piano è intelligente, ma fondamentalmente, se il pc o il telefono sono compromessi, non ci si può fidare di nessuno. Nel caso del malware bancario, vediamo che arrivano al punto di "emulare" un comportamento corretto, ma in realtà fanno qualcos'altro. Nel caso del tuo schema, potrebbe conservare una copia non contaminata di tutto ciò che viene trasferito e persino renderizzare la tua immagine usando quello, ma qualunque sia la cosa importante che presumo tu faccia dopo questo sarà compromessa con una seconda serie di dati maligni alterati.

Come altri già hanno sottolineato, non ti puoi fidare di tutto ciò che un dispositivo non affidabile dice o mostra. Hai bisogno di un'interfaccia affidabile per questo, o di un meccanismo di verifica come hai provato a creare, ma temo che riparare uno sfondo sia troppo facile per farlo. Non vorrei che qualcosa come la filigrana di un fotografo fosse tutto ciò che si frappone tra me e l'invio di migliaia di € sul conto bancario di qualcun altro.

C'è una soluzione che è in uso (almeno) in Germania per l'online banking, chiamata ChipTAN: il dispositivo non attendibile visualizza una rappresentazione grafica (è possibile utilizzare QR, ChipTAN utilizza un'animazione con cinque barre sfarfallio, perché il lettore è molto più economico da costruire) e avere un dispositivo fidato (qui, una piccola scatola di lettori con cinque fotosensori e un display che si collega al chip della tua banca) leggono e visualizzano tali informazioni. I dispositivi ChipTAN ti consentono quindi di creare un numero di autorizzazione transazione legato alle informazioni che hai appena visto.

Hai paura che il messaggio venga perso per sbaglio e non venga visualizzato? Hai paura che il messaggio venga modificato, dicendo a qualcuno che hanno speso solo $ 10 quando hanno speso veramente $ 10.000? O hai paura che il malware agisca in modo affidabile su qualsiasi importo inferiore a $ 1.000, ma improvvisamente smettere di chiedere conferma se il cattivo ragazzo trasferisce $ 10.000? Se questo è il caso, forse il tuo lato server non deve occuparsi di dispositivi non affidabili quando il tuo rischio supera una certa soglia. Ad esempio, potresti richiedere l'autenticazione a due fattori per importi superiori a $ 1.000, quindi non ti fidi completamente del telefono per ogni transazione. Imposta i tuoi limiti in base a quanto ti fidi (o non ti fidi) dei dispositivi telefonici.

E le cose che non possono essere controllate con soluzioni tecnologiche possono spesso essere affrontate con audit.

L'utente può occasionalmente (e in modo casuale) convalidare le informazioni sul display in realtà ciò che il server ha inviato. Possono farlo in molti modi diversi: possono fisicamente andare al server e guardare la sua visualizzazione nativa; possono usare un secondo dispositivo (forse un altro modello di telefono fornito da un altro fornitore); possono connettersi al server tramite browser web e ricontrollare in questo modo; oppure possono tornare più tardi e controllare i log del server. Oppure il server potrebbe occasionalmente inviare le informazioni in due modi, utilizzando canali laterali come SMS o e-mail per fornire conferma.

Se un utente controlla uno su ogni quattro messaggi, il dispositivo inaffidabile ha una probabilità del 25% di essere scoperto ogni volta che presenta un messaggio falso. Se sei il cattivo in controllo del dispositivo inaffidabile, quelle sono davvero cattive probabilità di essere in grado di causare danni a lungo termine ai messaggi senza essere scoperti. (Ciò richiede che l'utente sia casuale nelle verifiche di controllo: ricontrollare ogni volta che l'ultima cifra è zero rappresenta un modello che l'utente malintenzionato potrebbe sfruttare.)

Ovviamente, come con qualsiasi soluzione che coinvolga persone fragili, il problema è la diligenza. Se un sistema si dimostra affidabile per il primo mese, la maggior parte delle persone smetterà di controllarlo dopo due mesi. Questa è la natura umana. L'autenticazione a due fattori in situazioni ad alto rischio aiuta a risolvere questo problema.

Si potrebbe pensare a un piccolo display sul dispositivo che mostra le informazioni più critiche (ad esempio ID chiamante, impronta digitale o importo - a seconda del caso d'uso). In alcune altre situazioni puoi usare qualcosa di difficile da forgiare come, per esempio, ci sono cuffie criptate che eseguono un fingerprinting "verificato" della voce.

E quello che puoi fare è usare un codice QR in modo che un utente sensibile possa vedere e convalidare una firma digitale su un dispositivo personale affidabile (ma limitato) e utilizzare ancora il dispositivo più grande e non attendibile per eseguire un'elaborazione normale (pensa a Internet di stampa caffè).

Il problema principale è che, una volta compromesso l'unico canale di comunicazione, tutto ciò che ne viene fuori è sospetto. Speri che il punto finale sia in grado di rilevare, recuperare dal problema. Inoltre, una volta compromesso l'endpoint stesso, il compromesso sul traffico è discutibile. Anche se il compromesso del punto finale è qualcosa che non dovrebbe essere tentato, perché c'è una reale possibilità di essere scoperti. Ecco perché le soluzioni basate su token OTP coinvolgono calcoli fuori banda del token.