Consenti di impostare sia l'URL del server che la chiave pubblica: buco di sicurezza?

Question

Consenti di impostare sia l'URL del server che la chiave pubblica: buco di sicurezza?

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

0

Abbiamo un sistema di licenze in cui il nostro software, un prodotto commerciale che vendiamo alle persone, contatta il nostro server di licenze quando inizia a ottenere un OK per l'esecuzione.

Contatta l'URL della licenza e restituisce un file XML firmato con la nostra chiave pubblica. Verifichiamo la firma con la nostra chiave privata, costruiamo un file XML da inviare e firmiamo con la nostra chiave privata. L'app utilizza quindi la chiave pubblica per verificare che ci provochi e agisca sulla risposta.

Stiamo cercando di consentire l'override dell'URL e della chiave pubblica con i valori impostati nella configurazione dell'app. L'override dell'URL verrebbe utilizzata per consentire ai clienti di testare il nostro nuovo server delle licenze. Sostituire la chiave pubblica è gestire il caso in cui la nostra chiave privata diventa nota e dobbiamo cambiarla.

Tuttavia, mi sembra che qualcuno possa ignorare entrambi per fare in modo che puntino al server usando la loro chiave pubblica e ora hanno dato a tutti la possibilità di ignorare il nostro assegno.

È un buco nel sistema? E se è così, è una cattiva idea permettere di essere sovrascritto? Se possiamo tranquillamente ignorarne uno, ma solo uno, penso che sia la chiave pubblica a consentire l'impostazione nel file di configurazione.

O c'è un altro modo per fare tutto questo?

digital-signature license-enforcement

posta David Thielen 24.10.2018 - 13:24

fonte

2 risposte

Leggi altre domande sui tag digital-signature license-enforcement

Come sfruttare CSRF usando il modulo HTML per salvare i dati? [duplicare] Come si può resettare completamente UEFI in caso di infezione del firmware?

score 2 · Answer 1

Risposta breve: Sì, se qualcuno crea il proprio server di licenza e sostituisce la chiave pubblica, sembra che dovrebbe essere in grado di utilizzare il proprio software senza pagare una licenza. Non hanno nemmeno bisogno dell'URL per questo.

La risposta un po 'più lunga:

Se ho capito bene, il client convalida la firma con una chiave pubblica che viene spedita nel software (e successivamente può essere sovrascritta). Sembra che il software abbia un metodo isAnswerSignatureCorrect() , che potrebbe essere facilmente modificato per restituire sempre true. Questo è ciò che erano i primi tempi del software cracking.

Si può anche eseguire un server web locale, reindirizzare l'host del server delle licenze a localhost e crackare il software, non è nemmeno necessario sovrascrivere l'URL nella configurazione.

Quello che sto cercando di dire qui: se il tuo pubblico è disposto a spingersi fino a costruire il proprio server di licenza che restituirebbe la struttura XML corretta per rompere la propria licenza, allora il metodo corrente che stai usando non lo farà tenere premuto molto a lungo.

Overriding the public key is to handle the case where our private key becomes known and we have to change it.

Se temi che ciò accada, dovresti pensare di affrontarlo per primo. Memorizza la tua chiave in un HSM, fagli firmare la risposta. Se un HSM "reale" è troppo costoso, dai un'occhiata ai prodotti Yubico.

Se temi di perdere l'accesso alla chiave privata, valuta la possibilità di generare una seconda chiave e spedire la chiave pubblica di entrambi.

Overriding the URL would be used for letting customers test our new license server.

Considerare la spedizione del software con un elenco hardcoded di server consentiti. Oppure aggiungi una route / header / urlparam alla richiesta dell'host del server delle licenze corrente per consentire che la richiesta venga gestita da un nuovo sistema senza dover cambiare host.

Potresti utilizzare il blocco della chiave pubblica per assicurarti che l'applicazione comunichi solo con un server che serve un certificato di proprietà della tua organizzazione.

score 1 · Answer 2

Sì, è un buco. Suggerirei di aggiungere entrambe le licenze all'applicazione e scegliere quella corretta in base all'URL o utilizzando un sistema CA, in cui inserire un certificato della propria CA nell'applicazione e quindi firmare i certificati per entrambi i server. Ciò consente anche la revoca e la generazione di nuove chiavi + certificati senza modificare le configurazioni utilizzando il sistema PKI standard.

Esempio molto semplicistico: inserisci una chiave pubblica della tua CA (la chiave privata dovrebbe essere idealmente su un token hardware o almeno un coputer con spazio vuoto). Si genera una coppia di chiavi per ciascun server e si firma la chiave pubblica con la chiave privata CA. Quindi includi la chiave pubblica firmata quando rimandi l'XML. L'app verifica quindi innanzitutto che la chiave pubblica sia firmata correttamente utilizzando la chiave pubblica CA hard-coded, quindi verifica l'XML utilizzando la chiave pubblica inclusa.

Ovviamente, l'utilizzo di certificati X.509 completi sarebbe ancora meglio, anche se un po 'più complicato.