Come dovrei considerare un opt-in per la sicurezza?

Question

Come dovrei considerare un opt-in per la sicurezza?

#1 da (1 voti)

0

Sto sviluppando update4j , un aggiornamento basato su Java e framework di avvio. Recentemente ho avuto una piccola controversia con un altro collaboratore e voglio chiarire le cose.

Ho poche parole possibili; c'è un aggiornamento lato client che legge un file di "configurazione" remoto. Quel file contiene tutte le informazioni necessarie per scaricare i file dell'applicazione.

Inoltre, esiste una funzione di attivazione per firmare i file e verificare ogni download con una chiave pubblica. Ciò dovrebbe impedire agli hacker di modificare i file nella configurazione o modificare i file dell'applicazione remota effettivi. Nella configurazione, accanto a ciascun file, viene aggiunto un campo signature che viene utilizzato dal programma di aggiornamento sul lato client per verificare la presenza di una chiave pubblica nota fornita durante l'installazione.

Ora, ho considerato l'opt-in dello sviluppatore se il certificato / chiave pubblica è utilizzato nell'updater quando si richiede di eseguire un aggiornamento. Altrimenti, il programma di aggiornamento ignora completamente il campo signature . Ma sostengono che se la configurazione contiene le firme, questo di per sé è considerato opt-in e dovrebbe costringere l'updater a verificare, e se l'updater non è mai stato a conoscenza di alcuna chiave pubblica e non l'ha mai richiesto, dovrebbe fallire.

Per citare :

No local certificate provided

If the config contains signatures (so the provider intends to secure the update), but no local certificate is provided, update4j downloads the configuration, the files and runs it. In my opinion, this is not secure. See src/test/java/org.update4j.integration.SigningTest.noCertificateWithSignatureTest()

Dal mio punto di vista questo non è necessario. Il "provider" è solitamente lo stesso team di sviluppo del programma di aggiornamento sul lato client (almeno hanno deciso come impostare l'aggiornamento). Se un hacker può accedere ai file o alla configurazione stessa e modificarla, il "provider" non cerca più sicurezza. Se cambiano le cose consapevolmente che l'aggiornamento non richiede mai alcuna firma, perché nel mondo questo hacker aggiungerà il campo signature ? Inoltre, rende davvero difficile aggiungere sicurezza solo per alcune installazioni (ad esempio una funzione di test) poiché dovresti aggiungere una firma, ma ora farà esplodere i vecchi client.

L'unico caso in cui potrei essere d'accordo non sarebbe sicuro è dove la config stessa non è stata compromessa, solo i file remoti. Qui il provider vorrebbe comunque verificare i file. Ma ricorda, il team di sviluppo non ha mai cercato sicurezza perché non ha configurato l'aggiornamento per controllare le firme.

Come gestiresti un caso del genere?

digital-signature

posta Mordechai 10.10.2018 - 19:45

fonte

1 risposta

Leggi altre domande sui tag digital-signature

È possibile che il firmware di un SSD sia infettato da malware / rootkit dannosi via Internet? È possibile essere infettati da virus, trojan o malware sfogliando i siti infetti o eseguendo l'installazione .exe?

score 1 · Answer 1

Fornirei un'opzione di configurazione sul lato utente per controllare cosa fare, con tre possibili impostazioni:

Controlla solo se è presente un campo signature . Questa opzione dovrebbe essere l'impostazione predefinita e consente all'utente di rinviare l'editore a verificare se la firma è presente o meno.
Controlla sempre e genera un errore se non è presente il campo signature . Questa opzione è per quegli utenti che desiderano (o necessitano) di garantire l'integrità del codice e non si fidano del publisher per richiederlo.
Mai controllare. Questa opzione è principalmente per gli sviluppatori o l'uso interno e probabilmente dovrebbe avere un grosso avvertimento su di esso.

La maggior parte degli utenti lascerà le cose al valore predefinito e quindi controllerà se l'aggiornamento fornisce una firma e nessuna se non lo fa, mentre chi ha bisogno di forzare abilitare o disabilitare il controllo può farlo.

Potresti inoltre considerare di fornire qualcosa di equivalente all'intestazione Strict-Transport-Security in HTTP. In sostanza, se un flag è impostato su un aggiornamento che è stato firmato, anche gli aggiornamenti futuri per lo stesso pezzo di dati devono essere firmati o non saranno accettati, anche se non hanno un campo signature valido.