Puoi segnalare i difetti nell'approccio dichiarato di aggiungere un nuovo dispositivo a un sistema di certificati SSL certificati esistente?

Question

Puoi segnalare i difetti nell'approccio dichiarato di aggiungere un nuovo dispositivo a un sistema di certificati SSL certificati esistente?

#1 da (1 voti)

2

Sto cercando di aggiungere nuovi dispositivi in un sistema sicuro. Un sistema sicuro in cui un server web è identificato dalla CA personalizzata e anche tutti i client lo sono. Cioè, ogni client che si connette al server ha il proprio certificato. Se devo aggiungere un nuovo dispositivo mobile al sistema sicuro, questi sono i passaggi.

L'app viene installata dall'utente dall'archivio app
Una volta aperta l'app, l'utente vede una stringa di 16 lunghezze (l'utente non deve effettuare il login per vederlo). Prima di visualizzarlo all'utente, la stringa viene inviata al server web tramite websocket, hash. Il server memorizza questa stringa con hash con ttl di 3 minuti.
L'utente accede al server web con le sue credenziali (ha le autorizzazioni per aggiungere un nuovo dispositivo) e inserisce la stringa di 16 lunghezza lì. Il server web lo blocca e confronta l'hash con quello salvato.
Il server web risponde all'app mobile sullo stesso websocket con un nuovo certificato. La risposta è simmetrica crittografata con la stringa di lunghezza 16.
Questo certificato viene utilizzato per future interazioni con il webserver, quindi non richiede alcun intervento umano.

Non è abbastanza sicuro? Quale sarebbe un modo più standard per farlo?

certificates certificate-authority

posta Srikanth 07.09.2018 - 13:50

fonte

1 risposta

Leggi altre domande sui tag certificates certificate-authority

Perché / come il browser inserisce gli SVG in linea alla fine del corpo? L'app store di Amazon è vulnerabile alle condizioni di race storage esterne?

score 1 · Accepted Answer

Non ci hai fornito un modello di minaccia , quindi Assumerò un ambiente aziendale standard e il valore dei dati protetti da questo schema è inferiore a $ 1 milione USD.

Questo schema suona davvero bene per me. La registrazione del dispositivo di bootstrapping è sempre difficile perché è necessario conoscere una sorta di segreto del dispositivo sia sul dispositivo che sul server.

Dici "app store", quindi presumo che si tratti di un dispositivo Android / iOS piuttosto che di un dispositivo IoT. Peccato, perché con un dispositivo IoT potresti essere in grado di farlo fabbricare con un segreto noto al tuo database o un certificato predefinito. Invece stai generando un segreto e la lunghezza (16 caratteri stringa) è un equilibrio di sicurezza e usabilità.

Alcuni pensieri:

Spero che il tuo websocket per caricare l'hash stia utilizzando TLS per rendere l'hash più difficile da sniffare (perché, perché no?)
Poiché un utente malintenzionato dovrebbe forzare l'hash e rubare un nome utente / password per un account autorizzato, è possibile evitare che il segreto non disponga di 128 bit completi di entropia.
Qual è il set di caratteri più grande che puoi utilizzare per il segreto senza causare problemi di usabilità? Probabilmente UPPERS e numeri? Forse UPPERS, abbassa e numeri? Dovrai escludere caratteri che sembrano simili, 1 / I / l, O / 0, ecc.
Quando dici "La risposta è simmetrica crittografata con la stringa di 16 lunghezze" come stai? Stai eseguendo la stringa da 16 byte attraverso una funzione di derivazione della chiave per trasformarla in una chiave AES-128/256? Il websocket utilizza TLS e il segreto utilizza la crittografia manuale al suo interno? Hai considerato di aprire una nuova websocket a questo punto utilizzando le modalità TLS_PSK (pre-shared key) o PAKE (password key exchange autorizzato)?
Quando dici "Il server web risponde all'app mobile sullo stesso websocket con un nuovo certificato". Solo il certificato, o anche la chiave privata? Il modo corretto per farlo sarebbe quello di generare la chiave privata sul dispositivo (preferibilmente nel keystore sicuro Android / iOS se possibile) e inviare al server una CSR nel passaggio 2, in questo modo nessuna chiave privata viene mai inviata in rete, periodo.