Encrypt-function all'interno del codice PHP che devi pubblicare

Con il motore standard, non puoi. Ci sono un certo numero di offuscatori di codice disponibili così come diversi strumenti di protezione del codice PHP, ma nessuno ti offrirà una buona protezione contro un attaccante che sa cosa sta facendo.

C'è un altro problema che ho letto nella descrizione del tuo problema: ti sembra di voler proteggere le password o altri dati segreti usando l'offuscamento del codice. Se è così, allora fermati qui: non c'è modo di proteggere tali dati da qualcuno con un debugger se segui quel percorso. Tutto quello che puoi fare è rallentare un potenziale aggressore, quindi la tua unica speranza è che i dati che vuoi proteggere non valgano il tempo speso per recuperarlo.

Se devi davvero fornire una robusta sicurezza dei dati nella tua applicazione, dovrai trovare un altro modello (che dipenderà esattamente da quello che stai facendo, esattamente).

Bene, sai che ogni software dell'utente finale (sia esso un cliente, un cliente normale che sta visualizzando un video, ecc.) può essere decodificato.

E questo vale per qualsiasi soluzione come "scarica le chiavi da un server", perché una volta che il tuo programma è descompiled, l'utente ha accesso ad esso.

Non credo che nessuno qui sarà in grado di darti una soluzione migliore di quelle già fornite da strumenti commerciali, quindi se vuoi rendere più difficile per il tuo cliente, vai con quelle offuscamento - soluzioni di crittografia e speranza per il meglio.

Potresti anche provare ad usare alcuni hardwre personalizzati (come un token) che avranno parte del codice, o qualche funzione essenziale, al suo interno. E puoi anche avere qualche servizio web, in modo che il tuo cliente acceda il tuo webserver e appena ricevuto i dati dopo aver fatto qualche elaborazione. E, naturalmente, entrambe queste alternative hanno degli svantaggi.

Dato che il tuo commento ha chiarito che devi consegnare un'intera macchina (o VM) e se hai questo in mente, allora sei in una partita diversa. Dimentica di provare a fare qualsiasi cosa con o con il PHP, non è sicuro quando gli hacker hanno accesso ad esso e provare a farlo in quel modo è discutibilmente un errore.

La distribuzione dell'intera macchina ha tuttavia molte più possibilità di proteggere l'accesso. Probabilmente si può ottenere aiuto se si ha la possibilità di scaricare i derivati Linux in favore di un BSD che ha un modello di sicurezza più robusto a quanto ho capito.

La sicurezza è sempre relativa. Se hanno il controllo della scatola e sono determinati, dotati di risorse e abbastanza esperti passeranno attraverso qualsiasi cosa tu realizzi. Altre opzioni potrebbero essere più profittevoli nel senso di consentire loro di pensare di aver violato la sicurezza e la registrazione quando gli accordi di utilizzo sono stati interrotti perché tu li carichi di conseguenza.

Per una protezione aggiuntiva rispetto alla codifica già fornita, la deviazione da una configurazione PHP standard offrirebbe alcuni vantaggi e potresti utilizzare un modulo personalizzato basato su C in cui la chiave è compilata nel modulo e non esistente all'interno del codice PHP. Tuttavia, considera quale protezione esiste per i dati prima che vengano crittografati; PHP stesso è opensource e può essere modificato, quindi ci sono rischi intrinseci da ciò e le soluzioni hardware citate nelle risposte potrebbero quindi non essere d'aiuto e non essere immuni dal reverse engineering.

Steinberg ha utilizzato i dongle hardware per Cubase, e sono stati reimpiegati con successo anni fa e sono state rilasciate emulazioni software. Nonostante la sofisticata protezione anti-manomissione su chip come i rivelatori di luce e il monitoraggio della tensione del segnale, le schede di visualizzazione del set-top box hardware utilizzate per un servizio TV del Regno Unito chiamato on-digital sono state invertite con successo, presumibilmente da un concorrente, portando a carte clonate essere prodotto e la conseguente scomparsa dell'azienda. Lo scopo della protezione è di rendere il reverse engineering il più complicato, costoso e dispendioso in termini di tempo, ma non può mai essere prevenuto.

Quando consegnate un sistema funzionante nelle mani del vostro aggressore, non potete impedirne il reverse engineering. Non ci sono eccezioni.

Ma con una distribuzione intelligente di chiavi e certificati, puoi alleviare alcuni dei problemi. Se ciascun utente riceve la propria chiave e il proprio certificato (firmato da te), allora è possibile identificare in modo univoco quell'utente con qualsiasi cosa egli firmi. Condividere la sua chiave rivelerebbe l'identità della persona che l'ha condivisa.

Allo stesso modo, distribuendo le chiavi pubbliche per la crittografia dei dati in uscita, è possibile limitare la decrittografia solo alle macchine che possiedono la chiave privata associata.

IN RISPOSTA AL COMMENTO

only need the strictly confidential data somehow stored on the harddrive encrypted and the decryption should be only possible through my software.

Hai perso con "la decrittografia dovrebbe essere possibile solo attraverso il mio software" . Questo è assolutamente impossibile al 100%. Quello che hai descritto è, esattamente, DRM. Leggi la spiegazione di questo di Cory Doctrow da quasi dieci anni. Alcune delle persone più intelligenti e più motivate dal punto di vista finanziario hanno lavorato su questo e continuano a lavorare su questo fino ad oggi, e in nessun momento ha mai realmente funzionato. Perché non può.

Quello che puoi fare è decifrare solo sul tuo server o una soluzione simile. Il modo (l'UNICO modo) per impedire al client di decifrare i tuoi dati è di non dargli la chiave . Il che significa che non può essere lui a decrittografarlo.