è protetto da http del corpo crittografato

Question

è protetto da http del corpo crittografato

#1 da (0 voti)

-2

Sto lavorando a un progetto incorporato che deve comunicare con un server. Sia il server che il dispositivo hanno una chiave AES preinstallata.

Ho un dispositivo di rete che fornisce servizi http ma non https. La mia proposta è di crittografare AES i dati nel corpo del comando post.

Dato che ho l'IP del server, il tasto AES è univoco per questo dispositivo e ruoto IV con ogni sessione (le sessioni qui sono molto brevi), che cosa potrebbe essere il lato negativo invece di aggiungere https nell'incastonato dispositivo?

Sono nuovo di http e di servizi rilassanti. Per questo esiste un'intestazione http standard o l'uso di S / MIME?

TIA

http aes embedded-system

posta pilotjack59 23.02.2015 - 07:06

fonte

1 risposta

Leggi altre domande sui tag http aes embedded-system

Navigazione web anonimamente su un mac usando Firefox SSH e Tor [duplicato] utilizzando la crittografia asimmetrica per crittografare la chiave privata [duplicato]

score 0 · Answer 1

Come menzionato nei commenti, devi ruotare IVs ogni volta che invii un nuovo messaggio. Semplicemente non c'è una buona ragione per riutilizzare le IV, e anche un lieve riutilizzo IV molto probabilmente aprirà lievi falle nella sicurezza.

Se si cripta solo il corpo HTTP, questo lascia il proprio metodo HTTP, il percorso HTTP e le intestazioni HTTP tutte esposte in chiaro. HTTPS crittograferebbe questi componenti dei tuoi messaggi.

Potresti dire che non ti importa di un intercettatore che ascolta questi componenti, ma considera i seguenti problemi:

I cookie HTTP sono comunicati dalle intestazioni HTTP. Se si prevede di utilizzare i cookie di sessione, sarà necessario inviarli in un'intestazione in testo normale o reinventare completamente i cookie HTTP per l'utilizzo all'interno del corpo del messaggio crittografato.
HTTPS garantisce non solo la riservatezza, ma anche l'integrità. Nel tuo schema, un utente malintenzionato attivo può alterare i componenti del testo in chiaro esposti, che possono influire sul tuo sistema in modi inattesi.
Lo schema attualmente non descrive alcun modo per impedire attacchi di riproduzione. Un utente malintenzionato che ascolta un messaggio crittografato (anche quando è crittografato con una IV) può inviare di nuovo il messaggio crittografato correttamente per ripetere un'operazione passata. È necessario includere una sorta di meccanismo di contrasto per invalidare i messaggi precedenti. HTTPS è già sicuro contro gli attacchi di replay.
Forse il tuo protocollo non espone attualmente alcuna informazione tramite metodo, percorso o header HTTP (cioè, sono sempre gli stessi, la funzionalità crittografata del server serve solo un URL, per un verbo HTTP, senza cookie) . Tuttavia, un giorno, il protocollo potrebbe espandersi per utilizzare intestazioni e percorsi HTTP variabili e, a quel punto, potresti esporre informazioni riservate a meno che non aggiorni i tuoi sistemi a HTTPS.