Come posso essere sicuro che qualcuno non stia inviando dati falsi?

Question

Ho letto Stack Overflow da un po 'di tempo, ma questa è la mia prima domanda inviata.

Ho questo programma di tracciamento scritto in C# che raccoglie informazioni sull'utilizzo del computer locale e li invia a un server. I dati sono formattati in XML, inviati una volta ogni ~ 10 minuti.

Il mio problema: non importa quanto crittografo i dati XML (sia esso simmetrico o asimmetrico), qualcuno potrebbe sempre decompilare il mio programma di tracciamento C#, capire le convenzioni chiave/certificato/crittografia che uso e scrivere un altro programma che invia false segnala al server.

Il programma di monitoraggio funziona presupponendo che l'utente che lo esegue possa essere interessato all'invio di rapporti falsi.

Domande: 1) come posso essere sicuro (il più sicuro possibile) che i dati vengano inviati dal tracker reale anziché da un clone/falso? 2) Come posso offuscare il codice in modo abbastanza grave che il ripristino di chiavi/certificati/convenzioni di crittografia diventa quasi impossibile?

voglio spendere poco o preferibilmente non soldi sulla soluzione (così 500 $ obfuscators sono fuori discussione. Sono uno studente universitario e sono a buon mercato :)

Grazie in anticipo.

Answer 1

1. Un altro approccio: Supponendo di non modificare spesso l'eseguibile. crea un DigSig della tua immagine del file eseguibile client (HASH + Encrypt) e invialo insieme, in modo da autenticare il tuo client come vero client e non come versione modificata.

Tuttavia, questo non può impedire che i dati vengano inviati da un client completamente diverso che può acquisire il Digsig dall'immagine eseguibile.

Answer 2

In teoria, un'applicazione non è in grado di proteggere se stessa durante l'esecuzione in un ambiente non affidabile. Quindi, la risposta alla prima domanda è: "Non puoi mai essere sicuro che i dati vengano inviati dal vero tracker".

In pratica, l'offuscamento ostacolerà gli attaccanti fino a un certo punto. Il punto è determinato dalla qualità dell'offuscamento e dalla motivazione dell'attaccante. Quindi, la risposta alla seconda domanda dipende da chi è l'attaccante, da quanto sono capaci e quali risorse potrebbero applicare a questo problema. L'offuscamento che è "inferno/prossimo all'impossibile" per un laico immotivato da sbrogliare potrebbe essere banale per un esperto o qualcuno che può assumere un esperto.

Here is a list di alcuni obfuscator C#.

Answer 3

L'utente client dispone dei diritti di amministratore sulla macchina? Sembra il tipo di app che verrà installata da un amministratore, ma utilizzata da utenti non amministratori. In questo caso, potresti conservare la chiave o l'hash protetti dagli utenti normali ed eseguire l'app nel contesto dell'utente amministratore. Non ho molta familiarità con il keystore, ma mi aspetterei che tutte le versioni di Windows (almeno XP +) dispongano di questa funzionalità. Se non è il keystore, allora forse un file che si trova in una directory criptata che appartiene all'utente admin.

Se l'utente di destinazione dispone di diritti di amministratore locale, in realtà non vedo come è possibile arrestarli.

Answer 4

Sembra abbastanza senza speranza.Il tuo tracker probabilmente si affida a Windows per fornire le metriche, ad esempio chiamando GetUserName()/GetTickCount()/CollectPerformanceData()/etc. Quindi, un cattivo deve solo intrappolare il codice (indipendentemente da quanto è offuscato e senza doverti scomporre) in qualsiasi punto di interesse di Windows, sostituire i dati falsi e lasciare che il codice continui sulla sua strada.

La vita è troppo breve per battere la testa contro quei tipi di muri di mattoni.

Answer 5

Abbiamo utilizzato una soluzione hardware per fornire questa funzionalità richiesta.

Ho lavorato con un prodotto chiamato IronKey, è un dispositivo hardware che è in grado di generare firme digitali. Quando emettiamo il dispositivo, memorizziamo la chiave pubblica sul nostro server. quando la nostra applicazione client invia dati generiamo una firma utilizzando la chiave privata, una volta ricevuti i dati possiamo verificare che sia stata inviata dal client corretto utilizzando la chiave pubblica.

Answer 6

Come Raph Koster once put it, scrivendo la battaglia contro hacker nei giochi online client-server,

Mai fidarsi del cliente. Non mettere nulla sul client. Il cliente è nelle mani del nemico. Mai e poi mai dimenticarlo.

Purtroppo, per praticamente qualsiasi applicazione nel mondo reale che richiede che la potenza di elaborazione del client viene utilizzato, qualcosa deve essere messo sul client, e quindi perché a disposizione di un malintenzionato. La domanda che deve essere posta - come con qualsiasi misura di sicurezza - è quanto tempo e denaro sei disposto a dedicare a mitigare questo rischio?

Alcune persone amano far notare alle persone che chiedono informazioni su offuscamenti o meccanismi di licenza lato client, "oh non ha senso, alla fine si romperà". Ma questo significa perdere il punto: che lo scopo di tali misure è quello di spingere "alla fine" ulteriormente nel futuro, al punto che per un aggressore non sufficientemente determinato, sarà "mai".

Ad esempio: se la tua app ha inviato i propri dati via e-mail in chiaro, ciò potrebbe sconfiggere circa zero attaccanti. Inviandolo in e-mail rot13 sconfiggerebbe forse il 5% degli aggressori. L'invio crittografato utilizzando il nome utente come una chiave avrebbe sconfitto di più. L'offuscamento del codice di invio con un offuscatore gratuito avrebbe vanificato di più. Obfuscating con un offuscatore di livello commerciale avrebbe vinto di più. Richiedere ad ogni cliente di avere un dongle hardware sconfiggere 'tutti gli attaccanti più determinati', come piace dire la gente - ma questo sarebbe probabilmente un costo intollerabile.

Da "Sono uno studente universitario" Immagino che questo non sia il progetto più delicato di sempre. Utilizzare un offuscatore gratuito e criptare i dati inviati utilizzando alcune informazioni specifiche dell'utente come chiave. Probabilmente lo farò.