Funzionalità di accesso sicuro con bassa potenza della CPU

HTTPS non è troppo pesante per un RPi - sono sorprendentemente potenti e SSL è molto leggero in termini di utilizzo della CPU e della memoria. L'ho visto implementato su microcontrollori Atmega da 40 MHz.

Se non mi credi, considera il fatto che puoi usare SSH in un RPi senza problemi.

SSL sarà piuttosto pesante su un processore PI ARM rispetto alle connessioni HTTP vaniglia. Quando i normali processori del server erano a 1 GHz, ho verificato le prestazioni di SSL con vari acceleratori hardware SSL al momento. In genere, SSL scendeva al 15% delle prestazioni di HTTP vanilla per apache, IIS ecc.

comunque. È l'handshake SSL, cioè alla connessione, che utilizza la CPU. Quindi, se puoi minimizzare questo, l'utilizzo complessivo della CPU diventerà meno problematico.

Ci sono due strategie:

1. mappa il modello di prestazioni per la tua app. Se i client creano continuamente nuove connessioni SSL, potrebbero verificarsi problemi di prestazioni. Forse consideri di mantenere sessioni più lunghe tra le richieste e questo ridurrà il carico.
2. Utilizza SSL reciprocamente assicurato, io..e con certificati lato client. Ciò riduce il carico della CPU sulla connessione per avvicinarsi a quello del testo in chiaro di Vanilla HTTP.

SSH sembra funzionare abbastanza bene con il mio Pi (ma non applicabile in questo scenario)

Conosco un processore PowerPC a 50 MHz che gestisce un server SSL e gestisce abitualmente 70 client simultanei; Ho scritto il codice me stesso. SSL è non pesante. Inoltre, tossisco e strillo quando sento parlare di un processore da 1 GHz "lento": un Raspberry Pi sarebbe stato una stazione di gioco totalmente rad nel 2001 e Internet esisteva già in quel momento ...

Se hai del feticcio sui cicli della CPU, allora la buona idea è ancora non per progettare il tuo protocollo. Invece, utilizza un SSL configurato correttamente (ad es. Con curve ellittiche per la crittografia asimmetrica).

In pratica stai implementando un sistema di sessione. Ulteriori informazioni su come proteggerlo su link e link . Fondamentalmente vuoi impedire gli attacchi di hijacking e replay di sessione. Una delle difese è quella di associare la sessione a un indirizzo IP del client e richiedere una nuova autorizzazione se l'indirizzo IP cambia. Cerca di più sul Web, la parola chiave è "session hijacking".

Per la massima sicurezza, è necessario utilizzare HTTPS. È possibile ridurre al minimo la quantità di risorse utilizzate da HTTPS (SSL / TLS) durante l'handshake utilizzando i certificati RSA a 1024 bit anziché gli standard 2048-bit. Per la crittografia simmetrica, usa RC4 invece di AES, perché RC4 usa meno CPU, il che probabilmente è il motivo per cui Google lo sta usando, anche se dovrebbe cambiare presto con il supporto AES-NI.

In alternativa puoi configurare un proxy che permetta ai client in entrata di connettersi al proxy tramite HTTPS, e quindi il proxy può eseguire la crittografia / decrittografia e ottenere i dati effettivi dal Pi - questo permette al Pi di concentrarsi sul aspetti non correlati alla sicurezza di esso e scaricare il HTTPS se questo è davvero il problema - si noti che questo richiede una rete "sicura" tra il Pi e il proxy se ne avete bisogno per essere veramente sicuro.