Proteggere API Chiavi Segrete in una Spessa applicazione Client

Question

All'interno di un'applicazione, ho le Chiavi Segrete per calcolare un hash per una chiamata API.In un .NET applicazione è abbastanza facile da usare un programma come Riflettore per estrarre informazioni dall'assemblea a includere questi tasti.

È offuscando l'assemblea un buon modo per garantire la sicurezza di questi tasti?

Answer 1

Probabilmente non.

Guardare in crittografia e Windows' built-in di informazioni che nascondono i meccanismi (DPAPI e memorizzare le chiavi di un ACL-limitata chiave del registro di sistema, per esempio).Buono si sta andando ad avere per la sicurezza di cui avete bisogno per mantenere sullo stesso sistema come la vostra applicazione.

Se siete alla ricerca di un modo per impedire a qualcuno fisicamente seduto alla macchina da ottenere il vostro informazioni, dimenticare.Se qualcuno è determinato, e ha libero accesso a un computer che non è sotto il tuo controllo, non c'è alcun modo per essere sicuri al 100% che i dati sono protetti in ogni circostanza.Qualcuno che è determinato sarà ottenere, se vogliono.

Answer 2

Io non la penso così, come offuscamento (da quanto ho capito almeno) semplicemente pasticciare con i nomi di metodo per rendere difficile (ma non impossibile) per capire il codice.Questo non modificare i dati della chiave effettiva (sto indovinando che è stato memorizzato in una costante da qualche parte).

Se si vuole solo rendere un po ' più difficile da vedere, si può eseguire un semplice cifrare il testo in chiaro (come il ROT-13 o qualcosa del genere), in modo che almeno non sono memorizzate in chiaro nel codice stesso.Ma che certamente non ha intenzione di interrompere qualsiasi hacker determinato, ai tuoi chiave.Un forte metodo di crittografia non guida perché si sarebbe ancora bisogno di memorizzare la chiave per il codice, e non c'è niente di proteggerla.

L'unico davvero sicuro cosa che posso pensare è quello di tenere la chiave al di fuori dell'applicazione, in qualche modo, e quindi limitare l'accesso alla chiave.Per esempio, si potrebbe tenere la chiave in un file separato e quindi protetto il file con un sistema operativo a livello utente-restrizione di base;che probabilmente potrebbe funzionare.Si potrebbe fare lo stesso con una connessione di database (di nuovo, basandosi su l'utente a base di restrizione di accesso a mantenere utenti non autorizzati di database).

Ho giocato con l'idea di fare questo per i miei apps, ma io non l'ho mai messa in atto.

Answer 3

DannySmurf è corretto che non è possibile nascondere le chiavi dalla persona che esegue un'applicazione;se l'applicazione è possibile ottenere le chiavi, in modo che la persona può.

Tuttavia, Ciò che si sta cercando di realizzare esattamente?

A seconda di cosa si è, spesso, ci sono modi per raggiungere il tuo obiettivo, che non è semplicemente fare affidamento su come mantenere un segreto "segreto", sulla macchina dell'utente.

Answer 4

Tardi per il gioco, qui...

L'approccio di memorizzare le chiavi nel montaggio / assemblaggio config è fondamentalmente insicuro.Non è possibile una corazzata modo per memorizzare un determinato utente avrà accesso.Non mi importa se si utilizza il migliore / più costoso offuscamento del prodotto sul pianeta.Non mi importa se si utilizza PDAPI per proteggere i dati (anche se questo è meglio).Non mi importa se si utilizza un locale OS-chiave protetto store (questo è ancora meglio).Nessuno è ideale come tutti soffrono dello stesso problema di base:l'utente ha accesso alle chiavi, e sono lì, immutabile, per giorni, settimane, forse anche mesi e anni.

Più sicuro approccio è di assicurare le vostre chiamate di API con il vero e provato PKI.Tuttavia, questo è ovvio, le prestazioni se le tue chiamate API sono chiacchierone, ma per la stragrande maggioranza di applicazioni, questo è un non-problema.

Se le prestazioni non è un problema, è possibile utilizzare l'algoritmo Diffie-Hellman su asimmetrica PKI per stabilire un segreto condiviso chiave simmetrica per l'uso con un algoritmo come AES."condivisa" in questo caso significa condivisa tra client e server, non tutti i clienti / utenti.Non c'è hard-coded / cotto a chiave.Ovunque.

Le chiavi sono transitori, rigenerato ogni volta che l'utente esegue il programma, o se siete davvero paranoico, potrebbero time-out e richiedono la ricreazione.

Calcolati segreto condiviso chiavi simmetriche stessi vengono memorizzati in memoria solo, in SecureString.Sono difficili da estrarre, e anche se si fanno, sono solo un bene per un tempo molto breve, e solo per la comunicazione tra quel particolare cliente (cioè la sessione).In altre parole, anche se qualcuno fa incidere il loro locale tasti, che sono solo un bene per interferire con la comunicazione locale.Non possono usare questa conoscenza per influenzare gli altri utenti, a differenza di una cotta in chiave condivisa da tutti gli utenti tramite il codice / config.

Inoltre, l'intera chiavi stesse non sono mai, mai passati attraverso la rete.Il cliente Alice e server di Bob indipendentemente calcolare loro.Le informazioni passano per fare questo potrebbe in teoria essere intercettati da terzi Charlie, che gli permette di indipendentemente calcolare la chiave segreta condivisa.Che è il motivo per cui si usa quella (molto più costoso) asimmetrica PKI per proteggere la generazione della chiave tra Alice e Bob.

In questi sistemi, la generazione della chiave è spesso accoppiato con l'autenticazione e quindi la creazione di una sessione.Si "login" e creare il tuo "sessione" su PKI, e dopo che questo è completo, sia il client e il server in modo indipendente hanno una chiave simmetrica che può essere utilizzato per ordine di grandezza più veloce di crittografia per tutte le comunicazioni successive a quella sessione.Per l'alta scala server, per questo è importante salvare i cicli di elaborazione su decrittografia con l'utilizzo di dire TLS per tutto.

Ma aspetta un attimo:non siamo sicuri di sicurezza.Abbiamo solo ha impedito la lettura dei messaggi.

Si noti che è necessario utilizzare un digest del messaggio meccanismo per impedire che l'uomo-in-the-middle manipolazione.Mentre nessuno può leggere i dati trasmessi, senza un MD non c'è nulla impedendo loro di modifica.Così si hash del messaggio prima di crittografia, quindi inviare l'hash con il messaggio.Il server quindi re-hash payload su di decodifica e verifica che corrisponda hash che è stato parte del messaggio.Se il messaggio è stato modificato in transito, che non, e l'intero messaggio viene scartato / ignorato.

Il meccanismo finale necessarie per proteggere contro gli attacchi di tipo replay.A questo punto, si hanno impedito alle persone di leggere i dati, oltre a modificare i tuoi dati, ma non ha evitato che il semplice invio di nuovo.Se questo è un problema per la vostra applicazione, il protocollo deve fornire dati e sia il client che il server devono avere abbastanza stateful informazioni per rilevare un replay.Questo potrebbe essere qualcosa di semplice come un contatore che fa parte del crittografato payload.Si noti che se si utilizza un sistema di trasporto UDP, probabilmente hai già un meccanismo in grado di gestire pacchetti duplicati, e quindi può già fare con gli attacchi di tipo replay.

Ciò che dovrebbe essere ovvio, è sempre questo diritto non è facile.Pertanto, l'uso di PKI, a meno che non si può ASSOLUTAMENTE.

Si noti che questo approccio è ampiamente utilizzato nel settore dei giochi in cui è altamente auspicabile per spendere poco calcolare su ogni giocatore come possibile per ottenere una maggiore scalabilità, mentre allo stesso tempo fornendo protezione da hacking / occhi indiscreti.

Quindi, in conclusione, se questo è davvero qualcosa che è un problema, invece di cercare di trovare una memorizzare in modo sicuro le chiavi API, non.Invece, cambiare il modo in cui l'applicazione utilizza l'API (supponendo che si ha il controllo di entrambe le parti, naturalmente).Utilizzare una PKI, o utilizzare una PKI-simmetrica condivisa ibrida, se PKI sarà troppo lento (che è RARAMENTE un problema di questi giorni).Quindi non avete nulla memorizzati che è una questione di sicurezza.