Modo più sicuro (ad esempio HTTPS, POST, PGP) per inviare chiavi di decodifica attraverso il web?

Question

Modo più sicuro (ad esempio HTTPS, POST, PGP) per inviare chiavi di decodifica attraverso il web?

#1 da (3 voti)
#2 da (0 voti)

0

Sono nella fase finale di sviluppo del mio plugin Revit. Questo plugin è programmato in C # e distribuito tramite una DLL. Una delle DLL è un database SQLite crittografato (con dati proprietari) che si presenta sotto forma di una DLL. Attualmente, nelle fasi di sviluppo, la chiave di decrittografia per il database SQLite è codificata nella mia DLL principale (la DLL del programma). Per la distribuzione, dal momento che le DLL sono facilmente decompilabili, ho bisogno di un nuovo metodo per decodificare la DLL. La mia soluzione è di inviare le nostre chiavi di decodifica dai nostri server in modo sicuro al computer dell'host.

Stavo guardando in POST, pensando che fosse più sicuro di GET, ma alla ricerca sembra che sia ugualmente insicuro, solo più "oscuro" di GET. Ho anche esaminato HTTPS, ma Hostgator richiede denaro extra per l'utilizzo di HTTPS.

Ho bisogno di qualche consiglio - ci sono soluzioni personalizzate che posso fare per implementarlo?

encryption

posta theGreenCabbage 24.10.2013 - 17:00

fonte

2 risposte

Leggi altre domande sui tag encryption

Perché i server Java sono così scarsi e costosi? [chiuso] Utilizzo della memoria accettabile in funzione della dimensione dell'input

score 3 · Answer 1

Non puoi proteggere un DB che viene fisicamente consegnato e quindi decodificato sul computer di un Cliente dal Cliente stesso.

Non è possibile farlo in modo semplice ... È come dire che vuoi salvare una cassastrong in una casa di qualcuno e inviare qualcuno con una chiave, quando hai bisogno di accedervi. Vuoi assicurarti che nessuno prenda quella chiave se la sua mano. Stai chiedendo "Dove posso nascondere la chiave?" Ma comunque tu lo tagli, lui come togliere la chiave per aprire la cassastrong. Il proprietario della casa lo vedrà, lui può afferrarlo, può aspettare che la cassastrong sia aperta, poi fermarlo dalla chiusura ... Ci sono troppi buchi in questo sistema perché l' ambiente è non sicuro. Non puoi semplicemente proteggere un file in un ambiente non sicuro e allo stesso tempo tenerlo accessibile.

La soluzione semplicemente non fornisce mai tutti i dati al client in primo luogo. È necessario creare un servizio che fornisca i dati in base alle necessità.

score 0 · Answer 2

Questa non è una risposta diretta, ma temo che un commento sia troppo breve per completare il mio punto.

Stai cercando di tenere la chiave fuori dalla portata dei tuoi utenti. HTTPS in questo caso non aiuta troppo. Ecco perché: oltre a HTTPS, avrai bisogno di alcune informazioni di autenticazione passate dall'applicazione. Senza autenticazione, un utente usa semplicemente un browser e preme il link, voilà, la chiave di decifrazione / crittografia. Quindi si tratta di proteggere queste informazioni di autenticazione, che sono incorporate di nuovo in uno dei tuoi binari e sei tornato al tuo problema originale. Per evitare la de-compilazione, prova questi prodotti di offuscamento. Spesso fanno un lavoro abbastanza buono per proteggere il tuo da reverse engineering.

Per evitare che la chiave venga intercettata durante la trasmissione, è necessario HTTPS, ma se non è possibile utilizzarla a causa di problemi di budget, è possibile eseguire il rollover della propria crittografia asimmetrica su HTTP. Tutto quello che devi fare è crittografare la chiave sul server con una chiave privata e decifrare la chiave nel tuo programma con una chiave pubblica.