Protezione di un sistema distribuito in un ambiente "ostile"

https://stackoverflow.com/questions/4868170

28-10-2019
|

Domanda

Nella mia azienda stiamo sviluppando un sistema di grandi dimensioni, composto da diversi server. Il sistema è composto da circa 5 componenti logici. I dati sono archiviati in XMLS, MS SQL e SQLite. È un sistema .NET (principalmente), i componenti comunicano usando WCF e alcuni UDP personalizzati. I client accedono al sistema principalmente tramite UDP personalizzato o Web (ASP.NET e Silverlight).

Proteggere la comunicazione è facile, un po 'di SSL e un po' di sicurezza sul WCF e abbiamo finito.

Il problema principale che stiamo affrontando è che il sistema deve essere distribuito sul sito di un cliente, un cliente di cui non ci fidiamo necessariamente. Dobbiamo difendere i dati sui server e il software stesso dalla reverse ingegneria. Entrambi sono fondamentalmente importanti per noi.

Inoltre abbiamo bisogno di un switch di uccisione, vorrei qualcosa che distrugge i dati e il software, al comando o se non sono in grado di chiamare casa per un certo periodo di tempo.

La direzione a cui stavo pensando è usare TPM o qualcosa di simile: qualche soluzione di crittografia hardware, in combinazione con un altro servizio che potremmo mantenere internamente per crittografare tutti i software e i dati sui server, in modo che le chiavi provengano dal nostro server Al sicuro nel nostro sito, e forse la memoria che si tende dal TPM.

Come suggerisci di risolvere un tale problema?

AGGIORNARE 04/02 Sto cercando suggerimenti pratici o consiglio sui prodotti che potrebbero aiutarmi, quindi sto iniziando una taglie ...

Guarda ragazzi, fondamentalmente stiamo mettendo la nostra macchina nel sito del cliente (per motivi di attività e praticità), possediamo quella macchina e il cliente riceve tutto ciò che sta pagando in poche ore e può fare con i dati qualunque cosa voglia. Ma io gli algoritmi in esecuzione su quella macchina e alcuni dei dati archiviati ci sono i nostri segreti commerciali, che vogliamo proteggere. Idealmente vorrei che la macchina non funzionasse affatto nemmeno se non dico che va bene, e senza il mio ok per tutto ciò che sulla macchina rimanesse crittografato. Anche la tenda di memoria sembra un bel modo per proteggere la macchina durante l'esecuzione.

Anche idealmente vorrei che gli HD e lo stoccaggio su tutte le macchine esplodano non appena qualcuno si avvicina a loro con un cacciavite ... :-) Ma penso che lo porterebbe troppo lontano ...

AGGIORNARE 10/02 OK dopo aver fatto qualche ricerca, penso che proveremo qualcosa nella stessa direzione del sistema di crittografia PS3, tranne per il fatto che porteremo le chiavi per decrittoni il software e i dati dai nostri server. In questo modo possiamo decidere sulle nostre macchine se ci fidiamo del server che richiede le chiavi, possiamo ottenere un switch di uccisione solo ritenendo la macchina. Questo è probabilmente basato su TPM o qualcosa di simile, forse Intel's TXT ... Sono anche molto interessato alla memoria di memoria come importante funzionalità di sicurezza ...

A proposito, non possiamo risolverlo spostando le parti preziose del nostro sistema sul nostro sito, sia a causa dei requisiti aziendali sia perché non è tecnologicamente fattibile - avremmo bisogno di una larghezza di banda enorme ....

Soluzione

Quello che stai chiedendo, in effetti, è il Santo Graal. Ciò è approssimativamente equivalente a ciò che è stato fatto per le console di gioco, in cui hai una piattaforma di fiducia in esecuzione in un ambiente non attendibile.

Considera se puoi trattare o meno la macchina come compromessa dal giorno 1. Se puoi lavorare sotto tale ipotesi, allora le cose diventano considerevolmente più facili per te, ma qui non sembra terribilmente praticabile.

In termini di assicurazione effettivamente, ci sono alcune preoccupazioni:

È necessario crittografare il filesystem e utilizzare la decryption hardware
Devi isolare le tue applicazioni l'una dall'altra, in modo che i problemi di sicurezza in uno non comprometta gli altri
È necessario pianificare i problemi di sicurezza, il che significa mettere in atto strategie di mitigazione come un hypervisor sicuro

So che questi sono abbastanza vaghi, ma questa è davvero la storia delle protezioni della console di gioco negli ultimi due anni - se sei curioso di sapere come questo è stato risolto (e rotto) più e più volte, guarda ai produttori di console .

Non è mai stato fatto completamente con successo, ma puoi aumentare in modo significativo la barriera all'ingresso.

Altri suggerimenti

... Ad essere onesti, sembra che tu stia chiedendo come scrivere un virus nella tua applicazione che mi fa pensare che il tuo cliente abbia probabilmente più motivi per non fidarti di te che viceversa.

Detto questo, questa è un'idea terribile per una serie di motivi:

Cosa succede se la loro connessione a Internet muore o sposta gli uffici e scollegano la macchina per un po '?
Cosa succede se lo codifichi sbagliato e si inclina? Eliminazione dei dati anche se il cliente li utilizza correttamente?
Posso solo presumere che la tua richiesta implica che la tua applicazione non offra capacità di backup. Ho ragione? Sembra esattamente un prodotto che non comprerei.
Quanto sono preziosi i dati che la tua applicazione gestisce? Se viene eliminato che tipo di perdite finanziarie ciò comporterebbe per il cliente? Il tuo dipartimento legale ha firmato su questo e verificato che non puoi essere ritenuto responsabile?

Questa domanda viene posta così 2-3 volte a settimana e la risposta è sempre la stessa - qualunque cosa tu abbia dato all'utente non è più tua.

Puoi rendere più difficile per l'utente raggiungere i dati, ma non puoi impedirgli di arrivarci completamente. Puoi crittografare i dati, puoi mantenere la chiave di decrittografia su USB CryptoToken (che non espone la chiave segreta), ma in teoria se il codice può chiamare CryptoToken e chiedergli di decrittografare il pezzo dei dati, allora l'hacker può duplicare Il tuo codice (in teoria) e fai in modo che questo codice chiama CryptoToken per decrittografare tutti i dati.

Praticamente il compito può essere reso abbastanza complicato da renderlo impossibile ottenere i dati. A questo punto dovresti verificare quanto siano importanti i dati decrittuiti per l'utente.

Informazioni su Kill Switch: Questo non funziona. Mai. L'utente può fare una copia e ripristinarla dal backup se necessario. Può cambiare orologio per computer. Probabilmente può persino rallentare l'orologio del computer (se i dati sono così preziosi che è possibile investire nell'hardware di emulazione personalizzata).

Sui dati critici: A volte si scopre che la tua preziosa risorsa ha davvero poco valore per chiunque altro [e qualche altro aspetto della tua soluzione è]. Esempio: spediamo il codice sorgente dei nostri prodotti del conducente. È la risorsa più preziosa per noi, ma gli utenti non pagano per righe di codice, ma per supporto, aggiornamenti e altri vantaggi. L'utente non sarà in grado di utilizzare efficacemente il codice sorgente [rubato] senza investire la somma, paragonabile al costo della nostra licenza.

Sull'offuscamento: La virtualizzazione di pezzi di codice (ad es. VMProtect Product) sembra essere abbastanza efficace, tuttavia può anche essere bypassato con un certo sforzo.

In generale posso pensare ad un hardware personalizzato con sistema operativo su misura, sigillato come un macchina in contanti (in modo che il client non possa entrare senza interrompere il sigillo), con ispezioni regolari ecc. Questo potrebbe funzionare. Quindi il compito non è solo tecnico ma per lo più organizzativo: dovrai organizzare ispezioni regolari della macchina ecc.

Riassumere: se i dati sono Quello Prezioso, tenerlo sui tuoi server e offri solo una connessione Internet. Altrimenti puoi solo ridurre al minimo i rischi, non evitarli completamente.

Come dicevano tutti gli altri, non esiste un proiettile magico. L'utente potrebbe spegnere la macchina, ottenere l'HD come schiavo su altre macchine, eseguire il backup di tutto, invertire il codice e poi spezzarlo in modo contrario. Una volta che l'utente ha accesso fisico all'eseguibile, è potenzialmente compromesso e non c'è nulla da fare per fermarlo nel 100% dei casi.

Il meglio che puoi fare è rendere il lavoro di un potenziale cracker come l'inferno, ma non importa quello che fai, non sarebbe infrangibile.

L'uso di un'auto -distruzione in caso di qualcosa di sbagliato può essere risolto da un cracker che ha backup di tutto.

L'uso di una chiave in un driver USB aiuta a rendere la vita del cracker più difficile, ma alla fine può essere sconfitta da un cracker determinato competente: il codice che le cose non crittografate non possono essere in uno stato crittografato (inclusa la parte che ottiene la chiave), quindi È il grande punto debole. Hacking quella parte del codice per salvare la chiave da qualche altra parte sconfigge la chiave.

Se il software esegue l'autenticazione in un server remoto, questo può essere lavorato attaccando il client e diffondendo l'autenticazione. Se ottiene una chiave dal server, annusare la rete potrebbe essere utilizzato per intercettare i dati del server che contiene la chiave. Se i dati del server sono crittografati, il cracker può non crittografarlo analizzando il software che lo non protegge e pescando i dati non crittografati.

In speciale, tutto sarebbe molto più facile per un cracker se usa un emulatore per eseguire il tuo software in grado di salvare le istantanee della memoria (inclusa una versione non rispettata dell'algoritmo). Ancora più facile se può manipolare e appuntare la memoria direttamente durante l'esecuzione del software.

Se non ti aspetti che il tuo cliente non attendibile sia molto determinato, puoi semplicemente complicare le cose e sperare che non otterranno mai l'energia e l'abilità abbastanza per essere delegati per romperlo.

La soluzione migliore, a mio avviso, è quella di ottenere tutto il software nel tuo server affidabile e fare in modo che il loro server chieda al tuo server di svolgere il lavoro e mantenere i tuoi algoritmi nel tuo server. Questo è molto più sicuro e più semplice di tutto il resto, perché rimuove il problema fondamentale: l'utente non ha più accesso fisico all'algoritmo. Dovresti davvero pensare davvero a un modo per farlo eliminando le tue esigenze per mantenere il codice nel cliente. Tuttavia, anche questo non è infrangibile, un hacker può dedurre ciò che l'algoritmo fa analizzando ciò che è l'output in funzione dell'input. Nella maggior parte degli scenari (non sembra che questo sia il tuo caso), l'algoritmo non è il più importante nel sistema, ma invece i dati lo sono.

Quindi, se non riesci davvero a evitare di eseguire l'algoritmo nella festa non attendibile, non puoi fare molto di più di quello che hai già detto di fare: crittografare tutto (preferenzialmente in hardware), autenticare e controllare tutto, distruggere i dati importanti prima di qualcuno Pensa a backuplo se sospetti che qualcosa non va e rendi difficile da morire per qualcuno.

Ma, se vuoi davvero alcune idee e vuoi davvero farlo, eccoci:

Potrei suggerirti di rendere mutante il tuo programma. IE: quando decrittoni il tuo codice, crittografi con una chiave diversa e getta via la vecchia chiave. Ottieni una nuova chiave dal server e afferma che la chiave è essa stessa codificata in modo da essere molto difficile deridere il server con qualcosa che fornisce nuove chiavi compromesse. Fare una certa garanzia che la chiave sia unica e non sia mai riutilizzata. Ancora una volta, questo non è infrangibile (e la prima cosa che farebbe un cracker è attaccare proprio questa caratteristica).

Un'altra cosa: metti un sacco di aringhe rosse non ovvio che eseguono strani controlli di coerenza non sensorio, che molta versione falsa non funzionale del tuo algoritmo e aggiunge un sacco di overbloat complessi che non fa effettivamente nulla e afferma che funziona come previsto dal codice reale. Fai in modo che il vero codice faccia alcune cose che sembrano strane e senza senso. Ciò rende ancora più difficile il debug e il contrazione inversa, il baci del cracker avrà bisogno di molto sforzo nel tentativo di separare ciò che è utile da ciò che è spazzatura.

EDIT: E ovviamente, fai parte del codice spazzatura che ha un aspetto migliore di quello corretto, quindi un cracker guarderebbe lì in primo luogo, perdendo efficacemente tempo e pazienza. Inutile dire che offusca tutto, quindi anche se il cracker ottiene il semplice codice di corsa non crittografato, sembra ancora confuso e molto strano.

So che gli altri probabilmente colpneranno i buchi in questa soluzione - e mi sento libero di farlo mentre faccio questo genere di cose per vivere e accolgo con favore la sfida! - Ma perché non farlo:

Dal momento che stai utilizzando chiaramente Windows, abilita la protezione dell'unità Bit-Locker sul disco rigido con le impostazioni di sicurezza massime. Questo mi aiuterà a mitigare le persone che clonano la spinta come la mia comprensione - se sbaglio, dillo! - Il suo contenuto sarà crittografato in base alle impostazioni hardware di sistemi.
Abilita TPM sull'hardware e configuralo correttamente per il tuo software. Ciò contribuirà a fermare l'annusamento hardware.
Disabilita qualsiasi account non utilizzato da te e bloccare gli account e i gruppi di sistema per utilizzare solo ciò di cui hai bisogno. Punti bonus per la creazione di Active Directory e una VPN protetta in modo da poter accedere alla loro rete in remoto tramite una porta sul retro per controllare il sistema senza fare una visita ufficiale in loco.
Per sollevare la barra tecnica necessaria per entrare in questo, scrivere il software in C ++ o in qualche altro linguaggio non netto poiché il codice byte MSIL è facilmente disattivabile nel codice sorgente da strumenti gratuiti disponibili pubblicamente e ci vuole più abilità tecniche per il decompile Qualcosa in assemblaggio anche se è ancora molto fattibile con gli strumenti giusti. Assicurati di abilitare tutte le istruzioni della CPU per l'hardware che utilizzerai, per complicare ulteriormente le questioni.
Chiedi al tuo software di validare il profilo hardware (ID hardware univoci) del sistema distribuito ogni tanto. Se questo fallisce (come nell'hardware è cambiato), non è stato autodistrutto.
Una volta che l'hardware è stato convalidato carico il tuo software da un'immagine binaria crittografata caricata in un disco di RAM crittografato che viene poi de-crittografato nella memoria (non pinned!). Non appuntarlo o utilizzare un indirizzo di memoria costante in quanto è una cattiva idea.
Fai molta attenzione che una volta terminata la decrittazione, le chiavi vengono rimosse dalla RAM poiché alcuni compilatori ottimizzeranno stupidamente una chiamata Bzero/Memset0 non protetta e lascia la chiave in memoria.
Ricorda che le chiavi di sicurezza possono essere rilevate in memoria dalla loro casualità in relazione ad altri blocchi di memoria. Per aiutare a mitigare questo, assicurati di utilizzare più chiavi "fittizie" che se utilizzate, attiva uno scenario di rilevamento delle intrusioni ed esplodere. Dal momento che non dovresti bloccare la memoria utilizzata dai tasti, ciò consentirà alle persone di attivare più volte le stesse chiavi fittizie. Punti bonus se puoi avere tutte le chiavi fittizie generate in modo casuale e la chiave reale è diversa ogni volta a causa del #12 di seguito, in modo che non possano semplicemente cercare la chiave che non cambia .. perché lo fanno tutti.
Utilizzare il codice di assemblaggio polimorfico. Ricorda che l'assemblea è in realtà solo numeri che possono essere fatti auto -modificanti in base alle istruzioni e allo stato dello stack/quello che è stato chiamato prima. Ad esempio in un semplice sistema i386 0x0f97 (impostare byte se sopra) può essere facilmente l'istruzione opposta (imposta byte se sotto) semplicemente sottraendo 5. Usa le chiavi per inizializzare lo stack e sfruttare la cache L1/L2 della CPU se si è davvero voglio andare duro.
Assicurati che il sistema comprenda la data/ora corrente e convalida la data/ora corrente è entro intervalli accettabili. Iniziare il giorno prima della distribuzione e dargli un limite di 4 anni sarebbe compatibile con la curva a campana del fallimento hardware per i dischi rigidi in garanzia/supporto in modo da poter trarre vantaggio da tale protezione e consentirti un buon tempo tra gli aggiornamenti hardware. Al fallimento di questa convalida, fallo uccidere da sola.
Puoi aiutare a mitigare le persone che avvitano con l'orologio assicurandoti che il file PID venga aggiornato con l'ora corrente ogni tanto; Confrontare il suo ultimo tempo modificato (come dati crittografati e i suoi attributi di file sul file system) con il tempo corrente sarà un sistema di allarme precoce per se le persone hanno avvitato l'orologio. Sul problema rilevato, esplodere.
Tutti i file di dati devono essere crittografati con una chiave che si aggiorna sul comando. Imposta il tuo sistema per aggiornarlo almeno una volta alla settimana e su ogni riavvio. Aggiungi questo alla funzione aggiornamento del software che dovresti avere.
Tutta la crittografia dovrebbe seguire le linee guida FIPS. Quindi usa un crittografia forte, usa HMACS, ecc. Dovresti provare a colpire le specifiche FIPS-140-2-livello-4 data la tua situazione attuale, ma comprensibilmente alcuni dei requisiti potrebbero non essere fattibili dal punto di vista economico e realisticamente -2-livello-2 potrebbe essere il tuo limite.
In tutti i casi di autodistruzione, chiedi al telefono per prima cosa, così sai immediatamente cosa è successo.

E infine alcune soluzioni non software:

Se non può telefonare a casa .. come ultimo sforzo di fossato un dispositivo hardware personalizzato collegato a una porta seriale/USB interna che è impostata per attivare un relè che quindi si imposta un blocco di termite se rileva entrambi i casi, hardware o manomissione del software . Metterlo in cima ai dischi rigidi e posizionarli sopra la scheda madre farà meglio il lavoro. Dovrai tuttavia verificare con il tuo dipartimento legale per i permessi, ecc. Se si tratta di una situazione di approvazione militare degli Stati Uniti poiché presumo che tu sia negli Stati Uniti.
Per assicurarsi che l'hardware non sia manomesso, consultare i requisiti di sicurezza fisica FIPS per maggiori dettagli su come assicurarsi che il sistema sia fisicamente sicuro. Punti bonus Se se riesci a vedere su bullone/saldatura dei moderni rack che stai utilizzando in una vecchia custodia AS400 come camuffamento per aiutare a mitigare il movimento/manomissione dell'hardware. I ragazzi più giovani non sapranno cosa fare e si preoccupano di rompere "succhiare le vecchie cose", i ragazzi più anziani si chiederanno "wtf?", E la maggior parte di tutti lascerà il sangue alle spalle che possono essere usate in seguito come prova di manomissione se manomettono spesso i Caso tagliente, almeno in base alla mia esperienza.
Nel caso di una notifica di intrusione, lo spunta dall'orbita .. è l'unico modo per essere sicuro. ;) Assicurati solo di avere tutti i moduli e i requisiti legali per l'accesso compilati, quindi legale è soddisfatto della mitigazione del rischio o della responsabilità Notifica che ti dice che è esploso.

"L'unico modo per avere un sistema totalmente sicuro è distruggerlo con un martello"

Detto questo, è possibile avvitare con gli aspiranti hacker abbastanza da renderlo più problematico di quanto valga la pena. Se la macchina è una "scatola nera" in cui non riesce a accedervi direttamente, ma invece hanno programmi che la affrontano, allora la tua più grande minaccia è l'accesso fisico. Puoi bloccare le custodie e persino installare un piccolo elemento fragile nel caso che verrà scattato se la custodia è aperta ... Assicurati che le persone di servizio sostituiscano sempre questo articolo ... ti farà sapere se qualcuno ha aperto Senza autorizzazione (sì, è un vecchio trucco per adolescenti, ma funziona). Per quanto riguarda la scatola stessa, disabilita fisicamente eventuali bit di hardware (come le porte USB) di cui non hai assolutamente bisogno.

Se hai a che fare con una macchina che non è una scatola nera, crittografi l'inferno da tutto ... La crittografia a 256 bit è effettivamente impossibile da rompere senza la chiave ... allora il trucco diventa la chiave.

In teoria, potresti potenzialmente avere la chiave modificare (Rivilla nuovamente i dati) ed essere recuperabile solo da un processo che comunica direttamente con i tuoi server (sicuri).

Inoltre, segui tutto ciò che accade alla scatola, in particolare tutto ciò che accade nel software al di fuori del normale uso. Gran parte di questo non può proteggerti da qualcuno che è davvero, davvero determinato ... ma questo Potere Avvicinati che il tuo sistema è stato compromesso. (su cui puoi citare in giudizio il diavolo da chiunque sia entrato)

Per quanto riguarda l'interruttore di uccisione ... beh, i virus dormienti sono là fuori, ma come è stato detto, possono essere ingannati o partiti per caso. Suggerirei che invece di asciugarsi pulito, se sospetti una violazione, hai il sistema crittografa tutto ciò che può con una chiave generata in modo casuale, invia la chiave ai tuoi server (in modo da poter annullare il danno) e quindi "distruggere" File che utilizzava la chiave. (Molti trituratori di file là fuori possono distruggere i dati abbastanza bene da essere (quasi) impossibile da recuperare.)

Riassumendo le risposte, sì. Non ci sono soluzioni "perfettamente sicure" a questo problema, come sarebbe necessario crittografia omomorfa (che esistono ora solo sotto forma di prototipi limitati che richiedono quantità ridicole di calcolo).

In pratica, ciò di cui hai bisogno è la combinazione di ingegneria ingegneristica e di sicurezza dei requisiti adeguati (valutare le parti interessate, gli interessi, le attività preziose all'interno del sistema dispiegato, i possibili attacchi e i danni da ogni scenario di attacco di successo rispetto ai costi per difenderne.)

Dopodiché, vedrai che la protezione non è realmente necessaria, oppure puoi distribuire alcune misure ragionevoli e coprire altri "buchi" con cose legali o riprogettare del tutto il sistema, a partire dal modello di business (improbabile, ma improbabile, ma improbabile, ma improbabile, ma improbabile, ma improbabile, ma improbabile, ma improbabile, ma improbabile possibile anche).

In generale, la sicurezza è il problema dell'ingegneria dei sistemi e non dovresti limitarti solo agli approcci tecnici.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow