Un protocollo può essere protetto con la crittografia?

Question

Questo è qualcosa che ho sempre voluto imparare. Quando progetto un sistema (software o hardware) in cui più componenti comunicano tra loro, come posso implementare una semplice crittografia o altre funzionalità nel protocollo per una sicurezza di base?

Posso comunque cambiare il protocollo, dato che ho un accesso di basso livello fino alla serie di byte che sono trasmessi / ricevuti.

Modifica: sono interessato alla programmazione integrata, alla semplice crittografia over-the-wire per la sicurezza del protocollo.

Answer 1

Dici " sicurezza di base " ma questo non significa molto. Qual è il tuo modello di minaccia? Che tipo di attacco stai difendendo? Se stai trasmettendo i dati della carta di credito, dovrai utilizzare una crittografia avanzata, come RSA. Ma non riesco a pensare a un esempio che necessita di "meno" protezione. Se sei preoccupato per gli hacker che smontano il tuo codice, è già finito il gioco - se è interessante o prezioso, lo hackeranno. In caso contrario, hai perso tempo a implementarlo.

Answer 2

La soluzione più semplice è di gran lunga utilizzare solo un socket SSL anziché uno normale, come in stile HTTPS / FTPS.

Non vi è alcuna differenza nel protocollo tra HTTP e HTTPS, l'unica differenza è che operano su porte diverse (80 vs 443 normalmente) e una utilizza un socket normale e l'altra utilizza un socket crittografato SSL.

Answer 3

Non implementare la crittografia di base nel senso di progettarla da zero. È MOLTO difficile implementare correttamente la crittografia correttamente.

Concentrati invece sull'utilizzo della crittografia disponibile sulla tua piattaforma ... qual è la tua piattaforma?

EDIT:

Vedi questo SO post per un elenco di crittografia alternative, alcune delle quali dovrebbero funzionare abbastanza bene in un ambiente incorporato (es. CryptoPP e TomCrypt ).

Answer 4

OAuth può essere interessante per te, al fine di consentire il controllo dell'accesso tra varie API.

Se desideri semplicemente un canale crittografato di dati, è meglio sovrapporlo a quello del tuo protocollo; andare su SSL o SSH.

Answer 5

Se stai eseguendo una programmazione integrata, allora dov'è il problema della crittografia?

Finché rimani sullo stesso processore, ad esempio, la crittografia è inutile.

Se sei preoccupato tra i processori sul dispositivo, allora la crittografia può essere difficile, poiché un dsp non avrà necessariamente lo spazio libero per qualsiasi crittografia di qualsiasi complessità.

Se vuoi velocemente allora un algoritmo simmetrico è la soluzione migliore, e ci sono molti che puoi fare che sono buoni, come Blowfish o IDEA. Puoi memorizzare una chiave simmetrica univoca, quindi se riescono a smontare il dispositivo, verrà scoperta una sola chiave, ma ogni dispositivo dovrebbe avere la propria chiave.

Basta collegare ciascuna chiave al numero seriale, in modo che se si sta comunicando con un server, passare il numero seriale con il pacchetto e il server web possa cercare la chiave simmetrica corretta e decrittografarla rapidamente.

Se volessi fare una crittografia hardware veloce, per la mia tesi MSEE ho sviluppato una famiglia di crittografia che utilizza un calcolo di ordine arbitrario, che sarebbe difficile determinare la chiave in quanto può essere nel circuito hardware utilizzando microstrip, in quanto esiste nessuna elaborazione, verrebbe legato direttamente prima dell'antenna e tutto ciò che lo attraversa verrebbe crittografato.

Answer 6

Ci sono molte cose da considerare nella progettazione di un sistema sicuro. Solo per citarne alcuni:

• Scelta di schemi di crittografia simmetrica / assimetrica
• Algoritmo di crittografia (AES, Blowfish, DES)
• Scelta di protocolli noti (ad es. SSL)
• Gestione e distribuzione delle chiavi
  • Una sola chiave master (se violato, l'intero sistema è compromesso)
  • Chiave per dispositivo (la distribuzione delle chiavi può essere più difficile)
  • Protezione dei canali di distribuzione delle chiavi
• Un potenziale hacker avrà facile accesso ai dispositivi di campionamento? Per esempio. prodotto di consumo come X-box vs una scatola chiusa in un centralino telefonico. È più difficile proteggere dall'hacking se l'hacker ha accesso fisico.
• Fattori umani: ingegneria sociale ecc.
• Un sistema è sicuro solo quanto il suo collegamento più debole.

Ti suggerisco di leggere il materiale di Bruce Schneier per i principianti.

Answer 7

OAuth è sicuramente una considerazione. Inoltre, potresti prendere in considerazione WS-Security . Trasmettendo tramite un servizio Web, mantieni agnostico tutto il linguaggio e la piattaforma e aggiungendo WS-Security significa che la crittografia e la decrittografia sono a livello di applicazione (end-to-end). Quindi, fintanto che ti fidi che i messaggi siano al sicuro una volta che lasciano il mittente, sai che rimarranno al sicuro fino a quando il client non riceverà effettivamente il messaggio (ciò significa che non verrà decrittografato dal server e POI passato al client / destinatario, ma DOPO che l'applicazione ricevente ha il messaggio).

Quindi sostanzialmente OAuth per proteggere / autenticare le varie applicazioni e WS-Security per proteggere i messaggi che passano tra di loro.