Protegge l'applicazione dalla modifica

Lo scenario che descrivi è molto simile al concetto di "attestazione remota". Ci sono state molte ricerche su questo e ci sono due risultati principali:

• È necessaria un'ancora di attendibilità, come il TPM o un servizio di sistema attendibile, per misurare in modo sicuro la tua app e riportare i risultati sul server. Altrimenti puoi sempre creare un simulatore che generi le risposte corrette [1].

• Una volta implementata e utilizzata tutta l'infrastruttura di trusted computing, non è ancora possibile impedire o persino rilevare lo sfruttamento di vulnerabilità nell'app con ulteriori garanzie rispetto all'implementazione della tecnologia di overflow standard anti-buffer di oggi.

Quindi, se vuoi implementarlo oggi, la tua opzione migliore è l'offuscamento del codice. Fondamentalmente, vuoi implementare un meccanismo di protezione da copia, come se fosse stato implementato e rotto per decenni.

[1] Ci sono stati dei progressi molto interessanti che sfruttano i limiti di calcolo e comunicazione della piattaforma client, ma questo è ancora sci-fi.

What are the flaws in this scenario?

Il difetto di base qui è che si presume che il partito remoto stia rispettando le proprie regole.

Hai un server con un programma.

Riceverai una richiesta di download.

A questo punto non hai idea di chi o cosa sia il downloader remoto.

Una volta scaricato, un avversario può salvarlo ovunque lo desiderino. Possono tentare di eseguire il programma in uno dei numerosi debugger, emulatori o hardware fisico. È piuttosto banale che l'avversario impedisca al tuo programma di comunicare con qualsiasi sistema remoto mentre eseguono il debug, lo smontaggio, l'esecuzione, la modifica o l'analisi.

That someone will be able to disassemble the algorithm to compute the hash from the program and later modify the program to send the same value to the server?

Il problema di base con l'invio dell'hash al server è che non vi è alcun incentivo per consentire al programma di inviare quell'hash.

Immagina un dispositivo standard con un firewall dell'applicazione. L'utente scarica ed esegue il tuo programma non modificato. Quando il tuo programma tenta di inviare l'hash al server, il firewall dell'applicazione apre un dialogo che chiede "Applicazione YourApp tenta di connettersi a Internet, vuoi consentire questo?" L'utente non ha alcun incentivo a dire di sì.

Ora immagina un avversario che ha modificato il tuo programma. Eseguono l'applicazione in un dispositivo standard con un firewall dell'applicazione. Ora, quando il firewall dell'applicazione apre un dialogo. L'avversario ha un incentivo a non consentire al programma di comunicare con il server.

do you think that this is still a lot of work for someone to do, and it may not be worth it?

Il problema della verifica remota del software è un problema fondamentale su cui si è lavorato per decenni. Esistono approcci che funzionano bene per scenari specifici e potenziali aggressori. Tuttavia non esiste una soluzione generale.

Per il tuo scenario, dove alcuni utenti remoti hanno il controllo completo sulla piattaforma hardware di destinazione, il binario dell'applicazione è facile da smontare e non c'è alcun incentivo per un utente a consentire alla tua applicazione di comunicare con il tuo server, nel migliore dei casi lo farai rilevare pochissime delle modifiche totali. Nel peggiore dei casi ogni singola modifica non verrà segnalata e i report non modificati ti daranno la falsa sensazione che nessuno stia modificando il tuo software.

Riguardo all'estensione:

Anche lo schema che proponi è facile da rompere: registro l'hash che il software invia al server, quindi modifica l'app e rispondo all'hash quando il server lo richiede. Anche se crei un protocollo in stile challenge-response (per fornire freschezza), posso eseguire il debug della tua app per scoprire come generare la risposta. Questo attacco è in genere sempre possibile e la tua sicurezza dipende completamente dalla quantità di tecniche di offuscamento e anti-debug. Puoi ingannare il 90% dei tuoi clienti con una sicurezza moderata, ma ricorda che richiede solo un ragazzo per pubblicare una "crepa" per il tuo programma e quindi tutti possono utilizzare una versione modificata che invia gli hash corretti al tuo server.

Le parole chiave per la ricerca corrente su questo argomento sono "attestazione del software" o "agenti mobili protetti". Questi meccanismi sono sicuri solo in base a requisiti piuttosto rigidi che sono difficili da ottenere nella pratica (google "sulla difficoltà di attestazione del software" e "attestazione basata su PUF").

Il modo migliore per risolvere questi problemi nella pratica, qui e ora, è spostare parti significative del servizio sul server. Se il valore effettivo deriva dalla comunicazione con il server, c'è molto meno incentivo a imbrogliare. Prendi in considerazione i giochi online. Forse puoi avere alcune "funzioni social" come classifiche, chat room o altri servizi che fornisci dal server?

Puoi rendere più difficile per un utente malintenzionato modificare i file, ma non puoi impedire la modifica di tutto ciò che dai alla fine all'attaccante.

Questo presuppone che l'attaccante abbia pieno accesso al suo computer. Trusted Computing Group ci sono alcuni lavori e altri fornitori per limitare le capacità del proprietario. Questi fidati moduli di calcolo sono utilizzati principalmente nelle console di gioco e negli smartphone. Ma non appena questa protezione viene spostata (ad esempio il telefono è "rooted"), si applica il paragrafo precedente.

Quelle modifiche includono il checksum inviato al server. Per dare un esempio degno di nota: nei Paesi Bassi il CEO di Nedap ha affermato che i loro computer di voto sono una macchina dedicata per scopi speciali che può essere utilizzata solo per le elezioni e nient'altro. WVSN e CCC hanno portato su di esso un programma di scacchi open source per dimostrare il CEO sbagliato. Come caratteristica speciale di protezione il computer di voto ha un pulsante che calcola il checksum del programma e lo visualizza per evitare manipolazioni. Il programma di scacchi ha mostrato lo stesso numero . ( articolo di Heise in tedesco).

Puoi renderlo più difficile utilizzando molti checksum diversi e non utilizzarli in modo semplice ma come parte dei calcoli: Skype utilizza i checksum per calcolare la destinazione dei JMP come tecnologia anti-debug. Un breakpoint standard modificherà il programma debug e quindi lo farà saltare nei posti sbagliati. Skype è stato in seguito decodificato eseguendo una seconda copia come oracolo. ( Ago d'argento su Skype )

Un altro esempio che probabilmente si adatta meglio ai tuoi obiettivi è SecondLife. Second Life è un gioco online in cui i giocatori possono creare e vendere i propri contenuti. Nonostante il loro DRM qualsiasi tipo di informazione, che è inviata al client (trame, animazioni, suoni), è stata copiata illegalmente. Solo le informazioni che vengono conservate sul server (script utente) sono sicure. Ho approfondito questo argomento all'indirizzo ci sono Tecniche DRM per prevenire efficacemente la pirateria?

Potresti essere interessato all'approccio che Microsoft ha adottato con Authenticode e .NET.

link