Best practice: utilizzo di una singola chiave privata come persona o di più per l'identificazione di sé attraverso i domini?

5

Simile alla domanda qui , vorrei applicare la stessa domanda a una persona .

Ad esempio, ho impiantato un chip nella mia mano che contiene una chiave privata crittografata che funge da identificatore univoco personale. Dato che è legato alla mia persona fisicamente, ho solo una singola origine per la chiave che contiene.

Attualmente utilizzo questa chiave per l'autenticazione con i miei server. Quello che mi piacerebbe fare è registrare il componente pubblico di questa chiave per l'uso sul posto di lavoro.

Quali vulnerabilità vengono esposte alla mia chiave e ai server con cui lo utilizzo, assumendo che la chiave stessa sia adeguatamente sicura?
Dovrei prendere in considerazione la creazione di ulteriori chiavi private per identificarmi?

    
posta Steffan Donal 21.04.2016 - 13:00
fonte

2 risposte

2

L'utilizzo della stessa chiave privata in domini separati è sostanzialmente sicuro . Se esegui l'autenticazione su un sistema, non ti dai la chiave privata, e quel sistema non può impersonarti. In questo modo puoi utilizzare la tua chiave attraverso i sistemi di lavoro e personali e un sistema di lavoro non può quindi accedere ai tuoi sistemi personali.

Tuttavia, ci sono spesso motivi per usare chiavi diverse. Ad esempio, il tuo lavoro potrebbe avere una politica che richiedono una copia di tutte le chiavi private utilizzate per accedere ai loro sistemi. In tal caso, vorresti utilizzare una chiave separata.

C'è anche il problema della privacy che menziona Tylerl. Ed è un po 'più serio di quanto molti immaginino, perché nella maggior parte dei protocolli il certificato del client viene trasmesso in chiaro.

    
risposta data 26.04.2016 - 09:10
fonte
5

Il problema con questo approccio è che la stessa identità viene utilizzata da ogni destinazione, quindi i siti possono scambiarsi le note per vedere dove sei stato e tracciare correlazioni che potresti non voler esporre.

Ci sono diversi modi per risolvere questo problema, come quello utilizzato nella Chiave di sicurezza FIDO U2F . In questo caso, il dispositivo contiene una chiave simmetrica (non una coppia di chiavi asimmetriche) e l'hardware crittografico necessario in modo che la chiave segreta non debba mai lasciare il dispositivo.

Durante la registrazione del sito, il dispositivo crea una nuova coppia di chiavi pubblica / privata e invia la chiave pubblica al server insieme a un "ID chiave" per quella chiave. In caso di autenticazione, il sito invia al browser "l'ID della chiave" per quell'utente e si aspetta che la risposta sia firmata con la chiave pubblica corrispondente.

Ma invece di memorizzare la chiave privata corrispondente a ciascun ID di chiave, l'ID è esso stesso la chiave privata crittografata con la chiave simmetrica segreta del dispositivo.

Ci sono funzioni aggiuntive al protocollo per rendere impossibile il phishing, ma queste esulano dallo scopo di questa risposta.

Si noti che questo è sicuro solo perché il segreto non lascia mai l'hardware. Lo stesso principio vale per qualsiasi token di sicurezza hardware; è la differenza fondamentale tra una vera chiave di sicurezza e qualcosa come una pen drive; un dispositivo di archiviazione può essere copiato. Ciò è in disaccordo con le chiavi impiantate dall'uomo perché l'hardware necessario per eseguire calcoli crittografici effettivi mentre è alimentato da NFC richiede troppa area per adattarsi comodamente sotto la pelle.

L'utilizzo di un protocollo come questo offre il vantaggio aggiuntivo che è già supportato dai siti di altre persone, quindi tutto ciò di cui ti devi preoccupare è la tua implementazione locale. Ma non è così buono per le chiavi SSH e così via. Se lo utilizzerai come chiave SSH, dovrai farlo in qualche modo comunicare con l'agente chiave (che probabilmente significa scrivere un nuovo agente chiave).

    
risposta data 25.04.2016 - 04:09
fonte

Leggi altre domande sui tag