Gestione chiavi: rilevamento di una chiave compromessa?

0

Sto guardando la comunicazione tra la nostra app mobile iOS / Android da un lato e la nostra API dei servizi web REST dall'altro. Dal lato server, devo supporre che tutto ciò che ricevo sia sospetto. Immagino che l'app mobile possa essere stata decodificata, chiavi segrete / private raccolte, ecc.

Supponendo che stiamo facendo correttamente la comunicazione simmetrica protetta da HMAC, quando ricevo, autentichi e decifro un messaggio cifrato, so che il messaggio è stato inviato da qualcuno che possiede la nostra chiave segreta condivisa.

Questo messaggio potrebbe, naturalmente, provenire da un utente malintenzionato che ha ottenuto tale chiave segreta.

Mi chiedo se ci sia un protocollo formale o una buona pratica nell'area di gestione delle chiavi che risolva questo problema: come il ricevitore, posso rilevare che il segreto condiviso è, o potrebbe essere stato, compromesso? Penso che la risposta sia No, non esiste una soluzione così "facile". Ma se c'è una risposta mi piacerebbe saperlo!

Sospetto che non ci siano risposte nell'area di gestione delle chiavi. Questo è veramente "Come posso autenticare il mittente del messaggio, quando il mittente è la nostra app mobile scaricata dall'app store?"

Mantenere le firme valide dopo private compromissione chiave illustra come incorporare un timestamp sicuro da un provider di timestamp di terze parti attendibile. Non credo che questo aiuti, quando presumo che l'attaccante possa fare qualsiasi cosa l'app mobile compromessa possa fare. Questa è la natura dei servizi Web.

INFORMAZIONI AGGIUNTIVE

Dopo aver osservato l'attaccante (i) della nostra API dei servizi Web, sto cercando modi per migliorare la nostra architettura di sicurezza. Non voglio chiedere a qualcosa di così vago da essere inutile!

Ecco la nostra situazione come la capisco. Siamo ansiosi di ricevere raccomandazioni.

Abbiamo un sito web a traffico relativamente elevato (top 1500 di Alexis USA) che dura da molti anni. Ciò significa che abbiamo una strong esperienza nel proteggere il "normale" sito web e il traffico di aggressori.

Abbiamo scoperto che le API RESTful che si connettono alla nostra app mobile è un'arena completamente diversa. È probabile che non sto facendo le domande giuste. Non ho ancora capito veramente lo spazio del problema!

Tutto il traffico API è su HTTPS. Sono sicuro che abbiamo la sicurezza del livello di trasporto corretta perché fa parte della nostra esperienza "regolare" del sito web.

Il nostro utente malintenzionato utilizza correttamente i servizi Web con token di autenticazione corretti, ecc. Fino a quel punto (il punto di osservazione di quel particolare gruppo di attacchi) il nostro traffico API è testo semplice su HTTPS. Abbiamo app mobili per iOS e Android negli store Apple e Google Play. Lo sviluppo di app per dispositivi mobili è sotto il nostro controllo.

Da ciò possiamo concludere che il nostro aggressore è stato in grado di osservare il nostro traffico di app per dispositivi mobili in chiaro su HTTPS. O che il nostro attaccante ha decodificato la nostra app mobile (che è meno probabile dato il livello di abilità più alto necessario).

Quindi penso che i posti che dobbiamo migliorare:

  1. Comunicazione più sicura tra i nostri servizi web e le nostre app mobili.

  2. Meglio proteggere il nostro sito (lato server) dagli attacchi tramite i servizi web.

Detesto chiedere una domanda così ampia, ma posso ottenere consigli / riferimenti su come apportare questi miglioramenti alla sicurezza? Ho fatto diverse domande e ho ricevuto un eccellente consiglio durante la scorsa settimana, ma ciò non significa che io abbia ancora pienamente compreso lo spazio del problema!

    
posta Edward Barnard 16.09.2015 - 17:48
fonte

1 risposta

3

As the receiver, can I detect that the shared secret is, or may have been, compromised?

In breve: qualsiasi cosa tu metta nell'applicazione distribuita pubblicamente che condividi implicitamente con un attaccante e (s) non ti dirà una volta (s) che ha estratto queste informazioni segrete.

In dettaglio: Nello scenario che descrivi il segreto è incorporato nell'applicazione e quindi implicitamente condiviso con chiunque sia in grado di scaricare la tua applicazione. A causa di questa ampia distribuzione della chiave condivisa (solo offuscata) è necessario considerare che è già compromessa o verrà compromessa, almeno se c'è qualcosa di prezioso da ottenere quando si utilizza la chiave al di fuori del caso d'uso previsto.

Probabilmente l'unico modo per rilevare un compromesso definito è se la chiave è ovviamente utilizzata al di fuori dell'applicazione. Si potrebbe rilevare questo con metodi di rilevamento anomalie. Ma se non si rileva il compromesso non significa che la chiave non sia compromessa, potrebbe semplicemente significare che l'hacker è stato più intelligente di te e nasconde le sue attività abbastanza intelligenti in modo che il rilevamento delle anomalie non lo catturi.

    
risposta data 16.09.2015 - 19:21
fonte

Leggi altre domande sui tag