Puncte:0

Generarea de chei private pe baza listei de suite de cifrare disponibile

drapel my

Îmi construiesc propria rețea bazată pe MQTT pentru care aș genera propria mea rețea ca/server/client certificate pentru autentificare.

Scopul aici este de a păstra dimensiunile mesajelor cât mai mic posibil astfel încât să reducă traficul de lățime de bandă, dar știu deja că stratul TLS adaugă destul de mult traficului pe care îl trimite. Și anume, cu certificatele de client, ar trebui de fapt să trimit certificatul de client către server și invers la fiecare încercare de conexiune TCP care poate adăuga până la 8kb fără a trimite măcar un octet de date reale. (Sper că am înțeles partea aia bine până acum)

De asemenea, din moment ce mulți dintre clienții mei sunt dispozitive încorporate mici, care au doar un număr limitat de suite de criptare pe care le pot folosi, problema este și mai complicată.

De exemplu, aceasta este lista permisă de suite de criptare pe care un client le poate folosi:

CIPHERSUITE COD
TLS-PSK-CU-AES-128-CBC-SHA256 00ae
TLS-PSK-CU-AES-256-CBC-SHA384 00af
TLS-PSK-CU-AES-128-CBC-SHA 008c
TLS-PSK-CU-AES-256-CBC-SHA 008d
TLS-PSK-CU-3DES-EDE-CBC-SHA 008b
TLS-RSA-CU-AES-128-CBC-SHA256 003c
TLS-RSA-CU-AES-256-CBC-SHA256 003d
TLS-RSA-CU-AES-128-CBC-SHA 002f
TLS-RSA-CU-AES-256-CBC-SHA 0035
TLS-ECDHE-RSA-CU-AES-128-CBC-SHA c013
TLS-ECDHE-RSA-CU-AES-256-CBC-SHA c014
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 c027
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384 c028

Acum, în acest exemplu, singurele suite de criptare disponibile sunt PSK și RSA cele bazate. Desigur, mi-ar plăcea să folosesc EC ciphersuites, dar nu cred că aceasta este o opțiune pentru mine, având în vedere lista.

Acum câteva întrebări pe care le am sunt:

  • Având în vedere lista ciphersuite poate oricare dintre cheile private (CA, Server sau Client) să fie bazate pe CE sau trebuie să fie toate RSA?

  • Ar trebui să păstrez, de asemenea, pachetele individuale MQTT care sunt ambalate cu TLS cât mai mici posibil sau este ceva care va fi căptușit cu octeți suplimentari? (de exemplu, va face o diferență dacă pachetul meu este de 5 octeți sau pot scrie liber un pachet de 25 de octeți lung)

  • Care sunt alte lucruri de care ar trebui să țin cont dacă vreau să reduc lățimea de bandă a traficului?

  • Suitele de cifrare ECDHE-RSA îmi dau bătăi de cap. Ei folosesc EC pentru schimbul de chei, dar RSA pentru PKI? Înseamnă asta că un server poate avea cheie privată EC.

dave_thompson_085 avatar
drapel cn
Pentru a fi clar pentru orice suită non-PSK trebuie să trimiteți certificatul de server către client, iar pentru ECDHE-RSA, de asemenea, o semnătură; client-auth este opțional, dar dacă este folosit, trebuie să trimiteți și semnătura clientului cert _and_ către server. Generați propriile certificate cu conținut minim, pentru RSA pe 2048 de biți puteți ajunge fiecare la aproximativ 700-800 de octeți. Cu excepția 1.3, care nu sunt suitele dvs., restul unei strângeri de mână standard, inclusiv semnătura de autentificare client, poate fi cu aproximativ 700-1000 de octeți mai mult. Puteți face o mulțime de date (atât de multe dispozitive ca ale dvs.) cu o singură strângere de mână.
Puncte:1
drapel in

Având în vedere lista ciphersuite, oricare dintre cheile private (CA, Server sau Client) poate fi bazată pe EC sau trebuie să fie toate RSA?

Nu numai RSA, sau un secret simetric pre-partajat pentru TLS-PSK, desigur.

Rețineți că pentru suitele de criptare TLS-RSA, cheia va fi folosită pentru încapsularea cheii, adică pentru utilizarea cheii de criptare și pentru suitele de criptare TLS-ECDHE-RSA aveți nevoie de un certificat care poate fi utilizat pentru autentificarea entității cu utilizarea cheii pentru semnare. Adesea, ambii biți sunt setați pentru certificate specifice TLS.

Ar trebui să păstrez, de asemenea, pachetele MQTT individuale care sunt împachetate cu TLS cât mai mici posibil sau este ceva care va fi umplut cu octeți suplimentari? (de exemplu.va face o diferență dacă pachetul meu este de 5 octeți sau pot scrie liber un pachet care are 25 de octeți)

AES va cripta la un multiplu de 16 octeți, 3DES la un multiplu de 8. 3DES este încă relativ sigur, dar nu ar trebui să mai fie folosit cu adevărat. Din fericire, TLS folosește 3DES cheie, așa că există asta.

Suitele de cifrare ECDHE-RSA îmi dau bătăi de cap. Ei folosesc EC pentru schimbul de chei, dar RSA pentru PKI? Înseamnă asta că un server poate avea cheie privată EC.

Corect, dar E în ECDHE înseamnă efemer-efemer Diffie-Hellman. Atât clientul, cât și serverul vor genera (probabil/sperăm) o nouă pereche de chei pentru fiecare conexiune. Generarea perechii de chei pentru EC este la fel de rapidă ca și realizarea acordului de chei DH în sine, totuși, este mult mai rapidă decât generarea perechii de chei RSA.

Această pereche de chei este specifică sesiunii și nu trebuie să fie stocată, așa că nu trebuie să efectuați nicio gestionare a cheilor în jurul ei. Numai cheia RSA este folosită pentru autentificarea entității, deci cheia privată și certificatul face trebuie gestionate.

dave_thompson_085 avatar
drapel cn
Pe lângă completarea pentru blocarea limitei pentru criptare, suitele enumerate adaugă cel puțin 20 de octeți (unele 24 sau 32) pentru HMAC și toate adaugă un antet de 5 octeți (sau 13 pentru DTLS, dar care _elimină_ TCP care compensează mai mult).
drapel my
Cu toate acestea, MQTT nu folosește DTLS? Doar TLS peste TCP, nu?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.