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

13

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.

Sean Houlihane
źródło
2
„Coś, co pozostaje bezpieczne nawet z dostępem do oprogramowania układowego urządzenia”. oznacza, że ​​albo musisz użyć kryptografii asymetrycznej, której obliczenie jest kosztowne do odwrócenia, albo musisz przechowywać klucz symetryczny, w którym nie można go odzyskać lub wykonać w celu odzyskania (znany atak jawnego tekstu itp.). Zazwyczaj w tym drugim przypadku każda kopia produktu ma unikalny klucz, dzięki czemu odzyskanie z jednej próbki nie spowoduje uszkodzenia całego systemu; ale to oznacza, że ​​odbiornik musi przechowywać wszystkie te klucze.
Chris Stratton

Odpowiedzi:

8

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.

John Deters
źródło
Brzmi przekonująco i stanowi zupełnie inny problem, o którym tym razem nie myślałem zbyt wiele.
Sean Houlihane
2
Uważaj, że CTR nie zapewnia autentyczności danych. Powinieneś używać trybu szyfrowania uwierzytelnionego , chyba że rozumiesz, dlaczego autentyczność nie jest problemem w twojej aplikacji.
Gilles „SO - przestań być zły”,
10

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.

Aurora0001
źródło
1
„W przypadku procesora 2,9 GHz, przy założeniu, że każda„ operacja ”ma 1 cykl procesora (prawdopodobnie nieprawda)” - prawdopodobnie kompensowane przez procesory równoległe (takie jak GPU) działające z niższymi prędkościami, ale generujące wiele wyników na cykl [a nawet na procesorze IIRC możesz osiągnąć prawie 1 operację / zegar na jednym rdzeniu]. Nie zmienia to zbytnio rzędów wielkości.
Maciej Piechotka
@MaciejPiechotka To dobry punkt. Jak sugerujesz, rząd wielkości nie powinien mieć zbyt dużego wpływu, a przy skalach, nad którymi pracujemy, współczynnik 10 jest nadal dość nieznaczny (10 ^ 33 dni vs 10 ^ 32 dni nie będą miały znaczenia bardzo dużo!).
Aurora0001
1
System symetryczny, taki jak AES, jest problematyczny, chyba że każde urządzenie ma unikalny klucz - w przeciwnym razie wyciągnięcie go z jednej wyciętej próbki spowoduje uszkodzenie całego systemu.
Chris Stratton
4

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ą.

Simon Munro
źródło
2
Pytanie sugeruje SoC 2,5 GHz i wysyłanie wartości 32-bitowej co 10 minut. Ilość obliczeń potrzebnych do szyfrowania jest całkowicie znikoma. To prawda, że ​​SoC wydaje się być obezwładniona do tego zadania. Ale dla 32 bitów co 10 minut najtańszy podstawowy procesor, jaki można znaleźć, będzie więcej niż wystarczający.
Gilles „SO- przestań być zły”
3
Przy 10 minutowych odstępach nie ma znaczenia, ile czasu zajmuje szyfrowanie, liczy się tylko ilość energii . Musisz spojrzeć na szczegóły implementacji, takie jak obciążenia pasożytnicze, aby dowiedzieć się, czy szybki układ, który robi to w ciągu 1 ms lub powolny, który zajmuje 500 ms, wygra przy zużyciu energii, zakładając, że zarówno skutecznie śpią, gdy nie są zajęte. Silnik sprzętowy może być lepszy niż oprogramowanie, ale dla efektywności energetycznej - szybsze wykonanie zadania jest nieistotne.
Chris Stratton