Utilizzo del certificato client per autenticare un'app

I don't want people to send random requests to it using wget or anything similar. [...] Every copy of the app will have the (same) client certificate bundled with it.

Ok, è una cattiva idea. Non funzionerà. Riassumendo: se un valore segreto viene copiato in più di due posti, non è più un segreto. In tal caso, se alcune persone hanno interesse a "inviare richieste casuali usando wget", allora devono solo estrarre il certificato e la chiave privata da qualsiasi copia della tua applicazione, che è un attacco banale di reverse engineering.

Pensaci: se si nascondesse un valore segreto in un'applicazione ampiamente copiata, non ci sarebbero stati possibili ripping di DVD. Gli editori musicali non si lamentavano e digrigivano i denti al pensiero della pirateria basata sul software. Non ci saranno imbrogli nei giochi online.

Il solito slogan utilizzato per descrivere questa situazione è: la sicurezza applicata dal client non funziona .

Attenzione al contesto, però. Estrarre una chiave privata da un'applicazione compilata che utilizza quella chiave non è difficile; tuttavia , ciò non significa che le persone lo faranno. L'apatia è una delle forze più forti nell'universo dei computer. Tale reverse engineering avverrà solo se qualcuno, da qualche parte, si sentirà motivato abbastanza da investire un paio d'ore del suo tempo (al massimo) su quel compito. Questo può accadere solo se c'è qualcosa da guadagnare, anzi, "invia richieste casuali con wget" al tuo server.

Molti sistemi deboli, anche le applicazioni che cercano di imporre la sicurezza lato client, non vengono attaccati semplicemente perché nessuno si preoccupa di farlo.

La tua soluzione per quanto riguarda l'autenticazione va bene, perché si basa sull'autenticazione reciproca.

Se si utilizza Apache, è possibile ottenerlo facilmente (dopo aver configurato la CA e il materiale della chiave del client) aggiungendo le seguenti linee alla configurazione:

SSLVerifyClient require

Per proteggere il materiale della chiave sul telefono cellulare è necessario occuparsi di conservare le chiavi e i certificati in modo sicuro.

In iOS il portachiavi sarebbe una posizione appropriata o allo stesso modo il keystore in Android.

Se una chiave viene smarrita, puoi comunque inserirla nell'elenco di revoche (CRL).

Aspetta! Ricordare che se si desidera utilizzare TLS autenticato dal client, è necessario includere la chiave privata e il certificato. Ciò significa che l'app includerà una chiave privata e un certificato hardcoded. Quindi ecco alcuni rischi che è necessario prendere in considerazione:

1) Cosa succede se qualcuno esegue il reverse engineering della tua app ed estrae la chiave privata codificata in modo rigido?

2) Cosa succede quando scade il certificato hard codificato?

La linea di fondo qui è che tutto ciò che è codificato nel codice sorgente è una cattiva idea.

Sarebbe meglio se tu aggiungessi un elemento di iscrizione al codice di registrazione dell'utente che consentirà a un nuovo utente di generare il materiale chiave richiesto e i certificati in collaborazione con il tuo sito web. La chiave privata deve essere generata sul dispositivo e il certificato firmato dalla CA del tuo sito web. Non devi preoccuparti di terze parti affidabili perché solo il tuo sito deve avere fiducia nella CA e nei certificati client.

Dovrai anche includere meccanismi di revoca e riemissione di nuove chiavi, perché dovrai gestire gli scenari di dispositivi persi / guasti / rubati.

Questo approccio è debole come controllo di sicurezza e non aggiunge valore di autenticazione. Altri commentatori hanno ragione sul fatto che un certificato incorporato in un'app viene facilmente estratto da un attore malintenzionato. TUTTAVIA, esiste un modo sicuro per farlo .

Il tuo obiettivo di nascondere l'interfaccia API del server dietro una connessione TLS che richiede l'autenticazione reciproca per evitare che sia rilevabile e potenzialmente attaccabile attraverso la rete è solido e strongmente raccomandato. Sfortunatamente, il sovraccarico per farlo correttamente è troppo grande per i casi di utilizzo che non richiedono una sicurezza elevata.

Il certificato sul lato client deve essere emesso per utente . Per fare ciò, è necessario disporre dei componenti PKI appropriati che si affacciano su Internet o essere contattati da una terza parte. L'installazione di licenze e applicazioni deve includere un processo per l'utente che si registra con la CA e riceve un certificato univoco che può quindi essere memorizzato dall'app (utilizzando un archivio certificati crittografati del sistema operativo o altri mezzi sicuri) e utilizzato per l'autenticazione TLS esattamente come avevo pensato di utilizzare un certificato distribuito nell'app.

Inoltre, potrebbe essere necessario prendere in considerazione la possibilità di gestire la revoca dei certificati, che il server Web dovrà verificare come parte della convalida del certificato prima di completare l'handshake TLS. Ad esempio, se il tuo cliente paga una tariffa mensile per il servizio e emetti certificati con scadenza di 1 anno, dovresti probabilmente revocare i certificati dei clienti che non ricevono più il tuo servizio, ma i certificati non sono scaduti.

Le grandi aziende utilizzano certificati per questo scopo e simili. Possono stare in piedi CA e la gestione per loro abbastanza facilmente e giustificare il costo in molti casi d'uso, compresa la protezione dei servizi Internet pubblicati esattamente in questo modo.