Jaki jest wpływ zasilania na szyfrowanie mojego ruchu czujników?

Biorąc pod uwagę typowy typ aplikacji, czujnik zasilany bateryjnie, dokonujący odczytów (wartość 32-bitowa) co 10 minut, jaki jest prawdopodobny wpływ na żywotność baterii, jeśli wybiorę prosty nieszyfrowany protokół nadawany na żywo, w porównaniu z szyfrowaną transmisją?

Załóżmy, że moje dane nie są szczególnie tajne, ale zgodnie z tym pytaniem prawdopodobnie muszę rozważyć ich zaszyfrowanie, o ile faktycznie nie ma znacznych kosztów projektowych.

Dla uproszczenia załóżmy, że używam SoC nRF51822, który obsługuje stos BLE i prostszy protokół 2,4 GHz.

Ponieważ myślę o aplikacji produktu komercyjnego, a nie o jednorazowej instalacji, szyfrowanie wymaga intensywnego przetwarzania, aby przerwać (powiedzmy co najmniej 500 USD z chmury obliczeniowej 2016), a nie zwykłego zaciemnienia. Coś, co pozostaje bezpieczne nawet z dostępem do oprogramowania układowego urządzenia.

Większa część mocy prawdopodobnie zostanie przeznaczona na transmisję RF, a nie na cykle procesora spędzone na procedurach szyfrowania. Każdy dodatkowy przesyłany bit będzie kosztować więcej energii niż proponowane szyfrowanie. Oznacza to, że jeśli zastosujesz naiwne podejście, takie jak używanie AES w trybie CBC, ryzykujesz zwiększenie rozmiaru wiadomości, aby przenieść dodatkowe bity w każdym bloku.

Jeśli stwierdzisz, że Twoja firma potrzebuje danych do zaszyfrowania, rozważ użycie AES w trybie CTR w celu wygenerowania bitów szyfrowania strumienia. Tryb licznika jest praktyczny w przypadku przypadków, w których odbiór może być niewiarygodny i pakiety mogą zostać utracone. Będziesz musiał synchronizować liczniki, więc pamiętaj, że okresowe przesyłanie wartości licznika zwiększy koszty ogólne. I musisz zarezerwować kilka bajtów stanu, aby zatrzymać licznik, ponieważ ponowne użycie zaszyfrowanego strumienia bitów może prowadzić bezpośrednio do odzyskiwania danych.

Istnieje wiele metod szyfrowania, których można użyć do zabezpieczenia ruchu, a każda z nich ma nieco inne zużycie energii, więc wybiorę kilka popularnych opcji. Metodologia, której używam do oceny każdej metody, powinna mieć zastosowanie do wszystkich innych szyfrów, które znajdziesz i które chcesz porównać.

AES

AES jest jednym z najpopularniejszych algorytmów szyfrowania kluczem symetrycznym (co oznacza, że ​​używasz tego samego klucza do szyfrowania i deszyfrowania). Pod względem bezpieczeństwa AES to bezpieczny zakład:

Najlepsza publiczna kryptoanaliza

Opublikowano ataki, które są obliczeniowo szybsze niż atak z użyciem brutalnej siły, chociaż żaden z 2013 r. Nie jest wykonalny obliczeniowo.

- Wikipedia

Artykuł Biclique Cryptanalysis of Full AES opisuje, że AES-128 wymaga 2 ^126,1 operacji, AES-192 wymaga 2 ^189,7 operacji, a AES-256 wymaga 2 ^254,4 operacji do złamania. W przypadku procesora 2,9 GHz, zakładając, że każda „operacja” ma 1 cykl CPU (prawdopodobnie nieprawda), złamanie AES-128 zajęłoby bardzo dużo czasu . Przy 10 000 uruchomionych nadal potrwa to prawie wiecznie . Zatem bezpieczeństwo nie jest tu problemem; rozważmy aspekt mocy.

Ten artykuł pokazuje (na stronie 15), że szyfrowanie bloku za pomocą AES wykorzystało 351 pJ. Porównuję to nieco później po omówieniu kilku innych popularnych algorytmów.

SZYMON

Wcześniej zadałem pytanie o SIMON i SPECK , które warto przeczytać. SIMON przoduje w sytuacjach, w których trzeba często szyfrować trochę danych . W dokumencie, który wcześniej podłączyłem, stwierdzono, że SIMON 64/96 używa 213 pJ na 64 bity, co jest praktyczne, gdy trzeba wysłać tylko 32 bity ładunku.

SIMON 64/96 jest jednak znacznie łatwiejszy do złamania niż AES; dokument, który podłączyłem, sugeruje 2 ^63.9 operacji, więc nasza konfiguracja 10 000 procesorów może złamać szyfrowanie w ciągu zaledwie kilku lat , w przeciwieństwie do milionów tysiącleci.

Czy to naprawdę ma znaczenie?

Przy częstotliwości, którą planujesz nadać, odpowiedź jest prawie na pewno nie ; zużycie energii z kryptografii będzie całkowicie znikome. W przypadku AES zużyłbyś 50 544 pJ dziennie , więc tania bateria cynkowo-węglowa z 2340 J energii trwałaby znacznie dłużej niż żywotność urządzenia . Jeśli ponownie ocenisz obliczenia za pomocą SIMON, okaże się, że ma on również bardzo długą żywotność

Krótko mówiąc, chyba że transmitujesz bardzo często, radio jest znacznie bardziej związane z mocą . Wikipedia podaje zużycie energii w przedziale od 0,01 do 0,5 W. Jeśli transmitujesz przez 1 sekundę przy 0,01 W , zużyłeś już więcej mocy niż AES przez cały dzień .

Jednak w przypadku BLE prawdopodobnie powinieneś polegać na domyślnych zabezpieczeniach; BLE domyślnie używa AES-CCM do zabezpieczenia warstwy łącza :

Szyfrowanie w Bluetooth przy niskim zużyciu energii wykorzystuje kryptografię AES-CCM. Podobnie jak BR / EDR, kontroler LE wykona funkcję szyfrowania. Ta funkcja generuje 128-bitowe dane zaszyfrowane na podstawie 128-bitowego klucza i 128-bitowego tekstu jawnego za pomocą szyfru blokowego AES-128-bit, zgodnie z definicją w FIPS-1971.

Istnieją jednak pewne obawy, że istnieją luki w zabezpieczeniach związane z implementacją bezpieczeństwa warstwy łącza przez BLE; to nie jest wada AES; raczej Bluetooth SIG zdecydował się wprowadzić własny mechanizm wymiany kluczy w wersjach 4.0 i 4.1 . Problem został rozwiązany w 4.2, ponieważ eliptyczna krzywa Hellman-Diffie jest teraz obsługiwana.

O ile nie robisz szyfrowania przyspieszanego sprzętowo, koszt energii prawdopodobnie będzie wysoki, gdy wylądujesz, mając procesor, który jest zasadniczo obezwładniony na podstawowe potrzeby (nie kryptograficzne). Jednak w większości przypadków to właśnie radio zużywa najwięcej energii.

Ponieważ szczególnie patrzysz na SOC Bluetooth, rozważ BGM-111 , który ma przyspieszone sprzętowo krypto na chipie. Grałem z tym układem i wydaje się dobry, chociaż nie przyjrzałem się konkretnie funkcjom kryptograficznym.

Kolejna trasa i prawdopodobnie „najlepsza” trasa, jeśli chcesz mieć pewność, że nikt nie dostanie twoich kluczy, nawet jeśli zdemontują urządzenie. Ma zawierać układ TPM, taki jak OPTIGA TPM , który ma układy I2C i SPI TPM, które są obsługiwane przez jądra Linuksa.

Krótko mówiąc, przepalisz baterie bez specjalnego szyfrowania sprzętowego. Zbuduj płytkę z układem TPM lub wybierz nowocześniejszy SoC z wbudowanym kryptografią sprzętową.