Come utilizzo un ID ipotetico per l'autenticazione

Question

Come utilizzo un ID ipotetico per l'autenticazione

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

1

Questa domanda non si adatta bene a molte categorie, ma spero che qualcuno ci abbia provato prima.

Sto sviluppando una API Web che interagirà con un dispositivo fisico. Ogni nuovo dispositivo fisico ha il proprio ID univoco, ma tali ID sono ipotizzabili (essenzialmente sono sequenziali man mano che escono dalla catena di montaggio).

Quando il dispositivo viene collegato a un computer tramite USB, verrà avviata un'app client che l'utente avrà installato e sincronizzato i dati dal dispositivo all'API. Non possiamo fare affidamento su una relazione 1: 1 dei computer sui dispositivi, un utente potrebbe eseguire la sincronizzazione su più computer o più utenti potrebbero eseguire la sincronizzazione sulla stessa macchina.

Vogliamo effettuare l'autenticazione all'API utilizzando nient'altro che l'ID del dispositivo, ma non voglio che qualcuno sia in grado di falsificare un altro ID utente chiamando la mia API direttamente con un ID dispositivo diverso.

Mi chiedo cosa potrei fare con l'ID del dispositivo che potrebbe consentirmi di utilizzarlo in sicurezza per l'autenticazione.

Il mio primo pensiero è stato quello di crittografare l'ID con una chiave privata e quindi condividere la chiave privata con il software client. Il software client potrebbe quindi crittografare l'id del dispositivo prima di chiamare l'API e trasmettere quel valore crittografato. L'api lo confronta con un valore memorizzato e il tuo bene, ma sono preoccupato che sarà difficile proteggere la chiave privata quando deve essere memorizzata sul computer client.

Pensieri?

authentication cryptography

posta JoshReedSchramm 07.06.2012 - 02:45

fonte

2 risposte

Leggi altre domande sui tag authentication cryptography

Quale dovuta diligenza è necessaria per i moduli HTTP che vengono eseguiti in IIS? Elenco delle violazioni della sicurezza notabili [chiuso]

score 3 · Answer 1

Date le premesse, il problema non può essere risolto nel modo in cui lo si desidera. Hai detto che (1) l'ID del dispositivo è ipotizzabile, (2) l'ID del dispositivo è l'unico segreto che vuoi consentirci di usare, (3) vuoi autenticarti usando l'ID del dispositivo. Bene, non è risolvibile. Se riesco a indovinare l'ID del dispositivo di Alice, allora conosco tutti i segreti necessari per mascherarmi da Alice, e il tuo sistema non sarà in grado di distinguermi da Alice.

Hai menzionato qualcosa sulla crittografia con una chiave crittografica, ma se hai avuto un modo sicuro per condividere la chiave di crittografia con Alice (in modo da impedirmi di apprenderla), puoi semplicemente usare quella chiave per l'autenticazione - non avresti bisogno di usare l'ID del dispositivo. Tuttavia, questo è escluso dalle tue regole che nessun altro segreto è permesso. Quindi non capisco davvero cosa stai chiedendo o quali sono i veri vincoli qui.

Perché non ci parli del dominio dell'applicazione e di cosa stai cercando di ottenere e perché pensi che l'ID del dispositivo sia l'unica cosa che puoi usare per l'autenticazione. Potremmo essere in grado di proporre alcuni approcci o soluzioni che non ti sono venuti in mente.

Ad esempio, ecco un approccio che potresti prendere in considerazione. Quando il dispositivo si registra per la prima volta con il servizio, genera una nuova coppia di chiavi pubblica / privata, memorizza la chiave privata sul dispositivo e invia la chiave pubblica al server centrale. Potrebbe esserci una procedura di registrazione sicura in cui la chiave pubblica viene inviata al server centrale e registrata e associata all'account di Alice. In futuro, quando l'utente desidera eseguire la sincronizzazione su una macchina e richiamare l'API centrale, il dispositivo può impostare una connessione sicura al server centrale e autenticarsi utilizzando la sua chiave privata (si pensi ai certificati client e SSL), quindi inviare tali API chiamate. La comunicazione crittografata può essere instradata attraverso la macchina / desktop, in modo che non richieda fiducia nella macchina / desktop. La chiave privata non lascerebbe mai il dispositivo. Si prega di notare che questo è solo un esempio di un possibile approccio - a seconda delle vostre esigenze, potrebbe o potrebbe non soddisfare le vostre esigenze. Per favore non farti prendere dai dettagli di questo particolare esempio. Piuttosto, il punto che sto facendo è che se siamo chiari sui vostri requisiti e vincoli, potremmo essere in grado di fornire alcuni suggerimenti sul modo migliore per risolvere il vostro problema, entro i limiti che dovete affrontare.

score 3 · Answer 2

Se il tuo software gira su un computer, sul quale l'utente può eseguire software non fidato (ad esempio un PC standard, uno smartphone con root), sarà in grado di manipolare il tuo software .

È possibile utilizzare tecniche anti-debug, ma ciò rende solo un po 'più difficile per l'attaccante. C'è stato un discorso molto interessante chiamato Ago d'argento su Skype , che spiega come è stato analizzato Skype, nonostante l'uso di tecniche anti-debug.

La firma del software per impedire modifiche non funziona neanche: il codice che verifica la firma può essere modificato sostituendo il salto condizionato. Questa è una tecnica che è ben compresa da decenni perché il cracking del software copiato funziona allo stesso modo.

Hai proposto di firmare l'id del dispositivo con una chiave privata all'interno del tuo software. Ci sono diversi vettori di attacco qui:

Un utente malintenzionato può estrarre la chiave privata dal software e firmare la propria Valore
Un utente malintenzionato può utilizzare un debugger per modificare la variabile, che archivia l'id-dispositivo dopo che è stato letto dal dispositivo e prima che venga passato alla subroutine, che esegue la firma.
Un utente malintenzionato può manipolare il driver o il kernel del dispositivo, in modo che la chiamata di sistema per leggere l'id-dispositivo restituisca un altro numero.
...

TL; DR: non si fida del client.