Ambiente di esecuzione (sigillato) affidabile in Linux

No, questo non è possibile. Non in Linux e non in altri ambienti informatici. Non è un limite di Linux, è una limitazione della fisica.

Se esegui il tuo codice sul computer di qualcun altro ... è il loro computer, quindi controllano ciò che viene eseguito su di esso. Se hanno il tuo codice, possono vederlo correre, ispezionarne la memoria, fargli fare cose diverse se lo desiderano. Possono eseguire il codice in una macchina virtuale per facilitare il debug. Puoi provare a scoprirlo, ma qualunque cosa tu faccia, possono ignorare dando al tuo programma le giuste risposte, se sono sufficientemente motivati.

Intel SGX funziona perché quando compro un processore con SGX, non è realmente il mio computer, rimane parzialmente il computer di Intel. Intel mantiene il controllo sul software che viene eseguito nell'enclave SGX. Spedisci il codice crittografato e firmato con una chiave appartenente a Intel; l'enclave SGX decrittografa e verifica il codice con una chiave accessibile solo dall'enclave. L'enclave non mi appartiene, appartiene a Intel, quindi se non vuoi che il tuo codice sia retroingegnerizzato devi fidarti solo di Intel e non di me. Ricevo solo un blob crittografato e non riesco a eseguirlo altrove perché non riesco a decrittografarlo.

È possibile utilizzare SGX per le applicazioni che richiedono I / O. Devi solo dividere la tua applicazione in due parti: la parte fidata che viene eseguita in SGX e la parte dell'interfaccia utente (e backend dello storage) che viene eseguita all'esterno.

Tenere presente che le difese contro il reverse engineering sono molto costose (in termini di costi di debug e di supporto, nonché di tempi di sviluppo e perdita di prestazioni). Il reverse engineering e la modifica di un programma sono costosi; di solito è più economico pagarti per fare la modifica che farlo e mantenerlo internamente.

Se l'autore dell'attacco non è in grado di ottenere l'anello -1, puoi configurare un hypervisor e utilizzare Bispe, dal link . È sperimentale, ma sembra la soluzione software più vicina a ciò che stai cercando. Rimarrà sicuro finché i registri di debug non potranno essere letti dall'attaccante. Potrebbero essere necessarie alcune piccole modifiche per farlo funzionare al di sotto dell'anello 0, ma non è impraticabile. Se non ti aspetti che il malware sia in grado di ottenere lo squillo 0 in primo luogo, ma solo la memoria sonda con altri mezzi, allora dovrebbe funzionare immediatamente.

Physical access to a system allows attackers to read out RAM through cold boot and DMA attacks. Thus far, counter measures protect only against attacks targeting disk encryption keys, while the remaining memory content is left vulnerable. We present a bytecode interpreter that protects code and data of programs against memory attacks by executing them without using RAM for sensitive content. Any program content within memory is encrypted, for which the interpreter utilizes TRESOR, a cold boot resistant implementation of the AES cipher. The interpreter was developed as a Linux kernel module, taking advantage of the CPU instruction sets AVX for additional registers, and AES-NI for fast encryption. We show that the interpreter is secure against memory attacks, and that the overall performance is only a factor of 4 times slower than the performance of Python. Moreover, the performance penalty is mostly induced by the encryption.

Per quanto riguarda Intel SGX, anche se non supporta l'I / O, non è necessariamente un gioco fermo. È possibile aggiungervi I / O purché si utilizzino le API appropriate. Potresti anche eseguire un'intera istanza QEMU in un'enclave SGX, e credo che il supporto per questo sia ancora in fase di elaborazione.