Il punto importante è che non puoi nascondere segreti nel software: se alcuni software girano sull'hardware di proprietà dell'attaccante (qui, l'utente e il suo smartphone), allora l'attaccante può decodificare il codice dell'applicazione ed estrarre il segreto . Se fosse possibile proteggere il software da questo, non ci sarebbero software o pirateria video. L'industria dei media sarebbe molto interessata; hanno guardato in alto e in basso per una soluzione, e speso un sacco di soldi sull'argomento, e non hanno trovato nulla di veramente robusto.
Quindi hai bisogno di hardware antimanomissione , ovvero hardware che impedirà il reverse engineering. In uno smartphone, questo in effetti punta alla SIM card: le smart card sono, per design, resistenti alle manomissioni. Infatti, la SIM card è il componente hardware solo antimanomissione che può essere trovato in un tipico smartphone, quindi è necessario utilizzarlo. Tuttavia, ci saranno ulteriori sfide:
-
Per una protezione adeguata, non utilizzare la scheda SIM solo come archiviazione ; il punto di resistenza alla manomissione è di non lasciare mai che la chiave esca dalla scheda. Se la carta ha appena consegnato la chiave a chiunque la richieda, l'attaccante non avrebbe problemi a estrarlo. Quindi il calcolo completo deve avvenire all'interno della carta. A seconda di come è programmabile la carta, questo può essere o non essere facile; in ogni caso, il venditore della carta e l'operatore telefonico dovranno essere coinvolti.
-
Non c'è un orologio in una smart card. Se l'algoritmo dipende dall'ora corrente, allora quel tempo deve essere ottenuto dall'esterno e che "fuori" è il telefono, sotto il pieno controllo dell'attaccante. Il telefono potrebbe mentire. Ciò consentirebbe all'utente malintenzionato di generare i codici per, per esempio, l'anno successivo completo. A seconda di ciò che fai con i codici, questo potrebbe o meno essere un problema per te; ma devi tenerne conto nel tuo modello di sicurezza.
Il problema dell'orologio potrebbe essere evitato se generi i tuoi codici non con un orologio, ma con un contatore, come quello che viene fatto con HOTP . Una caratteristica dei token RSA SecurID è infatti che includono un orologio alimentato a batteria interno che l'utente non può manomettere; questa è una funzione costosa che spiega sia la dimensione (sostanzialmente più grande di un chip di smart card) sia il prezzo di questi token.
Un altro modo per evitare il problema dell'orologio è utilizzare la rete. Il codice nella smart card genererebbe una sfida casuale (diciamo 16 byte casuali), inviatela al telefono; il telefono dovrebbe quindi parlare con una Autorità di timestamp che firmerà la sfida insieme alla data e ora correnti e rimanderà indietro la firma. La smart card dovrebbe comunque verificare tale firma e verificare che la risposta contenga effettivamente il valore di sfida corretto. Questo processo assicura che la carta ottenga un non controllato, con nozione del tempo corrente con una precisione decente. Ma il protocollo è diventato piuttosto complesso e comporta l'accesso alla rete (non necessariamente facile, soprattutto quando il proprietario del telefono si trova in un paese straniero) e un server affidabile (che deve essere mantenuto).