Protezione di un'appliance

4

Scenario:

Siamo nella posizione di offrire un'appliance locale per eseguire una versione del nostro software proprietario, che viene normalmente fornito come SaaS.

Domanda:

Quali misure possono essere adottate per ridurre il banale reverse-engineering in un ambiente non affidabile, dove avranno accesso fisico alla scatola?

Chiaramente, è impossibile al 100% impedire completamente le perdite IP, poiché l'accesso fisico è l'accesso totale.

Detto questo, quali tecniche tecniche potrebbero essere applicate per rendere il reverse engineering difficile / non fattibile?

Modifica, per i dettagli:

  • Il progetto è internazionale, quindi limitato dalla legge
  • L'accesso alla rete è disponibile, quindi forse un piano potrebbe essere: archiviare le applicazioni su un filesystem crittografato, richiedere una connessione a uno dei nostri server per recuperare la chiave per la decodifica, o qualcosa del genere - qualcuno ha esperienza / insight?
posta Admin 11.07.2013 - 16:25
fonte

2 risposte

2

I token di sicurezza hardware menzionati possono fornire un po 'di sicurezza contro la pirateria.

Non sapendo che cos'è il tuo software o cosa fa, è difficile sapere quali soluzioni potrebbero funzionare. Stai mettendo la scatola sul posto perché è più efficiente? Stai mettendo la scatola sul posto in modo che il cliente possa amministrarla autonomamente? È perché il cliente lo sta eseguendo su una rete isolata?

Molte soluzioni di livello enterprise utilizzano rigorosi accordi di licenza e chiavi software sicure crittografiche con il nome dell'impresa acquirente e la data di scadenza in esse chiaramente indicata. Ciò significa che anche i dipendenti che rubano il codice ne hanno solo un uso limitato, in quanto all'origine e ai limiti temporali del suo utilizzo sono chiari.

Ma tutto questo fa poco o niente per proteggere contro il reverse engineering.

Gli offuscatori di codice e i compilatori offuscanti potrebbero aiutarti un po '. Di nuovo, dipende dalla tua applicazione, dal tuo team di applicazione, ecc.

Anche la resistenza alla manomissione fisica potrebbe essere d'aiuto, ma limita la tua capacità di supportare l'hardware fisico. L'industria delle carte di pagamento utilizza la rete metallica all'interno di alcuni dei loro hardware con le chiavi archiviate nella memoria volatile in modo che, in caso di manomissione del caso, vengano perse importanti chiavi di decrittografia, rendendo inutilizzabile la periferica. Tecniche simili sono applicate agli HSM (Hardware Security Modules), che sono effettivamente depositi resistenti alle manomissioni per la memorizzazione di importanti chiavi crittografiche.

L'intero gioco è la gestione del rischio. Le spese di avvio di una causa, il danno causato da una perdita, il costo della protezione del codice, tutto deve essere pesato. Pochi segreti sono così importanti che devono essere protetti a tutti i costi. Il ritardo nel mercato può costarti il tuo vantaggio in termini di tempo, consentendo a un concorrente di raggiungere una soluzione comparabile a un prezzo migliore prima di poter ottenere la versione bloccata fuori dalla porta.

    
risposta data 11.07.2013 - 17:12
fonte
0

Puoi usare l'offuscamento che può diventare ingombrante / complesso, e se non documentato, non è una buona idea, oppure puoi usare qualcosa come Sentinel HASP . In una situazione aziendale, tuttavia, SLA, TOS e le garanzie di annullamento producono un strong impatto quando sono esplicitate chiaramente. "NON SI ACCETTA / INGEGNERE L'INGEGNERIA / etc, ecc." Non fermerà la retromarcia, ma le aziende prendono seriamente la perdita finanziaria. Altre opzioni sarebbero la crittografia di avvio, le password tramite l'avvio, ecc., Tuttavia anche quelle possono diventare un mal di testa di gestione

MODIFICATO PER AGGIUNGERE UN LINK

link

    
risposta data 11.07.2013 - 16:37
fonte

Leggi altre domande sui tag