2009-03-06 29 views
11

Sto sviluppando un'applicazione intranet (C#) che utilizza alcuni dati (locali al server web) che vorremmo mantenere privati. Questi dati sono crittografati (AES) utilizzando un repository di dati legacy. Non possiamo impedire completamente l'accesso fisico alla macchina.Come si nasconde una chiave di crittografia in un'applicazione .NET?

Chiaramente, non avremo mai una perfetta sicurezza qui. Tuttavia, vogliamo rendere il più difficile possibile a chiunque di ottenere l'accesso non autorizzato ai dati.

La domanda è il modo migliore per memorizzare la chiave. La crittografia basata su un ID specifico della macchina è un'opzione, ma tali informazioni sarebbero prontamente disponibili per chiunque utilizzi uno strumento diagnostico sulla macchina.

La codifica nell'applicazione è un'opzione (è un'applicazione singola). Tuttavia, gli assembly .NET sono abbastanza facili da decompilare. Quindi, sarebbe meglio offuscarlo, usare un launcher di crittografia, compilarlo?

Oppure c'è un'opzione che mi manca?

Solo così siamo chiari, so che è praticamente una causa persa se qualcuno è determinato, ma stiamo cercando di renderlo il più difficile possibile entro i limiti.

risposta

5

La crittografia è incorporata nel sistema di configurazione .NET. È possibile crittografare blocchi del proprio file app/web.config, incluso il punto in cui si memorizza la chiave privata.

http://www.dotnetprofessional.com/blog/post/2008/03/03/Encrypt-sections-of-WebConfig-or-AppConfig.aspx

+0

Ecco come l'ho fatto in passato. –

+0

Se hai accesso alla macchina, non puoi semplicemente scrivere un'app che fa riferimento alle sezioni crittografate e ti consegnerà il testo in chiaro? Pensavo che fosse sicuro solo se non avessi avuto accesso alla macchina. – user74824

+0

@yahoo: sei corretto. – NotMe

2

Se qualcuno può semplicemente collegare un debugger al vostro programma, non c'è assolutamente niente che tu possa fare. Non dovranno calcolare la tua configurazione, disassemblare la tua app, ecc. Tutto ciò che devono fare è eseguire l'app - guardala usando la chiave - bingo.

L'offuscamento non è di aiuto in queste condizioni.

La migliore difesa consiste nell'utilizzare l'hardware per proteggere la chiave, che eseguirà la crittografia ma non fornirà la chiave stessa (a volte viene indurita dagli attacchi come sondare i fili, esponendo la memoria a basse temperature/radiazioni/altre cose del romanzo). IBM fa alcune cose appropriate (google IBM-4764) ma non è economico.

3

Parlando in termini offuscamento, ciò che si sta dopo è chiamato costante nascondere, cioè un mezzo attraverso il quale si trasforma un costante in, diciamo, un certo numero di funzioni e calcoli che vengono eseguiti in fase di esecuzione di ri-materializzare detti costante .

Tuttavia, questo rientra ancora nel dominio dell'offuscamento ed è suscettibile all'estrazione del codice, in cui l'utente malintenzionato esegue semplicemente il mapping del codice relativo a questa costante e lo esegue in un'applicazione separata per recuperare il valore; o scaricare la memoria dell'applicazione al punto giusto per scansionarla per il valore desiderato.

V'è un altro, leggermente metodo più avanzato di nascondere chiavi crittografiche in particolare, chiamato bianco-box crittografia, che impiega chiave-meno cifrari attraverso la generazione essenzialmente una funzione cifrario da una data chiave, li cottura insieme. Come suggerisce il nome, questo metodo è stato concepito per essere resiliente anche in uno scenario di attacco white-box (l'attaccante ha accesso al bytecode ed è in grado di ispezionare e manipolare l'eseguibile in fase di runtime).

Questi sono entrambi metodi abbastanza avanzati per raggiungere la sicurezza attraverso l'oscurità e potrebbe valere la pena di considerare modelli alternativi che non ti costringono a farlo in primo luogo.

Problemi correlati