Come sostituire un identificatore costante, per una risorsa su una rete, con uno variabile?

Tutti i moderni sistemi di autenticazione presumono al livello base che il client contenga un tipo di informazione che può essere utilizzato per dimostrare la sua identità e che le informazioni dovrebbero essere mantenute segrete. Questo potrebbe essere un nome utente, una password, una coppia di chiavi pubblica / privata, ecc ...

Se tali informazioni sono compromesse, la catena di autenticazione è rotta e il segreto deve essere cambiato.

Nelle domande e nei commenti si menziona che il client è completamente sovvertito, il che esclude fondamentalmente un sistema di autenticazione e che l'interazione dell'utente non è possibile. Ovviamente questo non è un problema e potrebbe essere reso molto più difficile con altri livelli di protezione per evitare che l'host venga compromesso in primo luogo.

Tuttavia, supponendo che il cliente sia completamente compromesso, la domanda non è come si implementa un sistema di autenticazione, ma come si esegue la verifica dell'integrità del client. Ciò potrebbe essere ottenuto attraverso l'analisi comportamentale più specificamente nel campo della prevenzione delle intrusioni / rilevamento. Se non ci si può fidare del client, l'uso di un agente endpoint sul client non sarebbe un'opzione e il metodo di rilevamento dovrebbe essere completamente esterno dal client.

Questo ti lascia probabilmente due opzioni a cui posso pensare:

• Prevenzione delle intrusioni basata sulla rete per mettere in quarantena i client sospetti dalla rete.
• Protezione basata su hypervisor come l'API vmSafe di VMware ( vmSafe ) che consente l'ispezione out-of-box di un client. Ciò significa che è possibile collegarsi a un'API che consente di ispezionare ciò che è in esecuzione sulla CPU e nella memoria senza essere all'interno della superficie di attacco e vulnerabile a un attacco. In questo caso, la protezione per il kit root e il rilevamento dei virus è già disponibile.

In entrambi i casi i tuoi requisiti esatti potrebbero non essere soddisfatti, non è chiaro il tuo intento preciso tuttavia è possibile. Tuttavia queste soluzioni sarebbero comunque utilizzate con un sistema di autenticazione sul client, solo per aiutare a rilevare se il client è compromesso.

Spero che ti sia d'aiuto, se non forse puoi dare alcune specifiche sull'implementazione esatta.

Molto probabilmente non esiste una soluzione al problema che hai abbozzato.

Ma ... Un approccio che potresti esaminare più da vicino è usare un TPM. Un TPM è un componente hardware affidabile che può essere utilizzato per archiviare i segreti crittografici e può predisporre il rilascio solo a software attendibili. A seconda delle esigenze particolari della tua applicazione, è possibile che ciò possa fornire almeno una soluzione parziale al tuo problema.

Tuttavia, ci sono un sacco di avvertimenti con TPM. I TPM non sono progettati per essere protetti dagli attacchi fisici, quindi se l'utente malintenzionato ha accesso fisico al dispositivo, dimenticalo, non è sicuro. Inoltre, non c'è molto supporto software per questo, quindi saresti sul filo del rasoio e ci sarebbero grosse sfide ingegneristiche. Inoltre, non tutte le macchine contengono un TPM.

Vedi anche Stato di implementazione di Trusted Computing e Remote Attestation e Verifica dell'integrità del software del server? .

Ma ancora una volta, la linea di fondo è più probabile che il problema non lo si possa risolvere con mezzi tecnici.

In uno scenario in cui ti fidi sempre del cliente, ma vuoi assumere il caso peggiore, avrai solo due opzioni

1) Fidati degli utenti molto più delle loro macchine (che non sono così inverosimili di un'idea) cioè una password molto più sicura di un file di password ecc.

2) Fidati di qualcosa di fisico (qualcosa sulla falsariga di un token RSA forse, o anche qualcosa di "semplice" come hashing dell'identificatore da un numero seriale o qualcosa di simile a quello

Suggerirei un modello di chiave pubblica-privata simile a ssh in aggiunta al tuo identificatore. Se il client su A vuole connettersi a B (che A è stato collegato in precedenza), A controlla che B non sia cambiato emettendo una sfida a B in base alla chiave pubblica host del server B (che A memorizzata dalle loro interazioni precedenti) che B può rispondere solo con la chiave host privata di B. Quindi A può autenticarsi con B (inviando la password su un canale crittografato o utilizzando la chiave privata / pubblica) e accedere al sistema B.

Certo, se un attaccante M ha la chiave dell'host privato per B, potrebbero impersonare B; ma devi fare del tuo meglio per proteggere le tue chiavi private dalla lettura del disco o della memoria (crittografare il disco, limitare i permessi di lettura, tenerti aggiornato sulle patch di sicurezza, ecc.)