CBC wiąże się z dwoma „niebezpieczeństwami”. Pamiętaj, że CBC działa w następujący sposób: aby zaszyfrować blok, najpierw XOR go z poprzednim zaszyfrowanym blokiem. IV to po prostu „poprzedni zaszyfrowany blok” dla pierwszego zaszyfrowanego bloku. Chodzi o to, że szyfr blokowy jest permutacją deterministyczną: z tym samym kluczem i tym samym blokiem wejściowym otrzymujesz te same dane wyjściowe. XOR z poprzednim zaszyfrowanym blokiem jest rozumiany jako „randomizacja”. A więc niebezpieczeństwa są następujące:

1. Blokuj kolizje.
2. Ataki z użyciem tekstu jawnego.

Blokuj kolizje są wtedy, gdy przez pecha lub brak losowości XOR bloku z poprzednim blokiem prowadzi do wartości, która została już wcześniej uzyskana.

Na przykład, jeśli używasz ustalonej IV (zero lub nie, nie ma to znaczenia), to dwie wiadomości, które zaczynają się tą samą sekwencją bajtów, dadzą dwa zaszyfrowane strumienie, które również zaczynają się tą samą sekwencją bajtów. Pozwala to osobom z zewnątrz („atakującym”) zobaczyć, że dwa pliki były identyczne do pewnego momentu, co można określić za pomocą szczegółowości bloku. Uważa się to za złą rzecz; Szyfrowanie ma zapobiegać tego rodzaju wyciekom.

Jeśli używasz licznika jako IV, nadal możesz mieć takie kolizje, ponieważ liczniki mają strukturę i "normalne" dane także ma strukturę. W skrajnym przypadku załóżmy, że zaszyfrowana wiadomość również zaczyna się od licznika (np. Jest częścią protokołu, w którym wiadomości mają nagłówek rozpoczynający się od numeru sekwencyjnego): licznik-dla-IV i ten licznik mogą się wzajemnie anulować z XOR, prowadząc cię z powrotem do sytuacji fixed-IV. To jest złe. Naprawdę wolimy, gdy systemy szyfrujące zapewniają poufność, nie wymagając żadnych złożonych wymagań dotyczących formatu zwykłego tekstu. Zegar o wysokiej rozdzielczości jako „licznik” może również powodować ten sam problem.

Ataki z użyciem tekstu jawnego mają miejsce, gdy osoba atakująca może wybrać część danych, które mają być zaszyfrowane. W przypadku CBC, jeśli napastnik może przewidzieć IV, może dostosować swoje dane w tekście jawnym, aby pasowały do ​​niego.

To jest podstawa ataku BEAST. W ataku BEAST osoba atakująca próbuje „przejrzeć” SSL. W SSL 3.0 i TLS 1.0 każdy rekord jest szyfrowany za pomocą CBC, a IV dla każdego rekordu jest ostatnim zaszyfrowanym blokiem poprzedniego rekordu: atakujący obserwujący połączenie i w pozycji do wprowadzenia pewnych danych w strumień może wypchnąć tylko tyle bajtów, aby wyzwolić emisję rekordu, obserwować go, a tym samym wydedukować IV, który zostanie użyty dla następnego rekordu, którego zawartość rozpocznie się od następnego bajtu, który przepchnie atakujący.

Ze wszystkich metod IV generacji, które pokazujesz, tylko pierwsza (IV wygenerowana za pomocą silnego kryptograficznie PRNG) ochroni Cię przed atakami z wykorzystaniem wybranego tekstu jawnego. To właśnie dodano do TLS 1.1.

W konkretnej sytuacji, takiej jak karty kredytowe w bazie danych, niektóre z możliwych ataków mogą mieć zastosowanie lub nie. Nie próbuj jednak zbytnio „iść na skróty”. Jeśli umieścisz dane użytkownika w bazie danych, mogą wystąpić ataki z użyciem wybranego tekstu jawnego: atakujący, który może zajrzeć do Twojej bazy danych (np. Za pomocą jakiejś techniki iniekcji SQL), może również działać jako „podstawowy użytkownik”, aby podać fałszywe numery kart kredytowych , żeby zobaczyć, co pojawia się w bazie danych.

W szczególności, w tym scenariuszu, jeśli używasz deterministycznego szyfrowania (i to jest dokładnie to, co otrzymujesz ze stałym IV, czy są zerami czy nie), wtedy atakujący może po prostu użyć brutalnej siły numery kart kredytowych: liczba składa się z 16 cyfr, ale jedna z nich to suma kontrolna, a pierwsze cztery lub sześć cyfr pochodzi z bank, a pozostałe niekoniecznie są „przypadkowe”, więc tego typu ataki mogą być skuteczne.

Podsumowując, jeśli używasz CBC, to musisz używać CBC właściwie , tj. z silnie losowym IV. Jeśli wolisz monotoniczny licznik (lub zegar), nie używaj CBC; zamiast tego użyj trybu, o którym wiadomo, że doskonale radzi sobie z monotonicznym licznikiem, np. GCM. Osiągnięcie bezpieczeństwa jest już wystarczająco trudne, gdy książka używa algorytmów kryptograficznych, więc należy unikać wszelkiej "kreatywności".

I oczywiście zawartość, która została zaszyfrowana danym kluczem, jest nie bardziej tajny niż sam klucz. Gdy osoba atakująca ma dostęp do odczytu do Twojej bazy danych, może mieć dostęp do czegoś więcej niż tylko do bazy danych - w szczególności do samego klucza szyfrowania. Zależy to od tego, gdzie przechowujesz klucz, a także od zakresu dostępu atakującego (wstrzyknięcie SQL, skradziona taśma z kopią zapasową, całkowite przejęcie systemu front-end, ...).

Głównym powodem używania IV jest zapobieganie dwukrotnemu umieszczaniu tego samego zwykłego tekstu w tym samym zaszyfrowanym tekście. Dzięki CBC szyfrujesz swój tekst w blokach. Załóżmy, że masz następujący tekst, a każda linia jest blokiem:

  AAAAAABBBBBBCCCCCCDDDDDD  

i

  AAAAAACCCCEEEEEEFFFFFF  

Bez użycia IV, zaszyfrowany blok dla AAAAAA byłby taki sam dla obu tekstów. Co oznacza, że ​​jeśli ktoś zauważy, że zaszyfrowane bloki są takie same na początku zaszyfrowanych plików, będzie wiedział, od czego zaczął się drugi plik.

Ideą IV jest to, że nigdy nie używasz go dwa razy. Musi być unikalny, ponieważ jeśli nie jest unikalny i jest szansa, że ​​użyjesz go ponownie, możesz napotkać wcześniej wspomnianą sytuację, w której możesz odzyskać część zwykłego tekstu ze względu na podobieństwa z zakrytą wersją znanego zwykłego tekst.

Przeanalizujmy jeden po drugim:

Losowa liczba poprawna kryptograficznie

Jesteś całkiem bezpieczny, zakładając, że kolizje są statystycznie nieprawdopodobne. Unikalność jest tym, do czego dążymy.

Każda stara „losowa liczba

Sama losowość nie jest tak naprawdę krytyczna - to możliwość kolizji. Jeśli twój RNG ma problemy, takie jak krótki okres lub statystycznie bardziej prawdopodobne wyniki (tj. Niejednolity rozkład), możesz uszkodzić odporność na kolizje, a tym samym osłabić CBC.

Niepowtarzalny, monotonny rosnący, nieciągły licznik (taki jak zegar o wysokiej rozdzielczości)

Zakładając, że jest w 100% niepowtarzalny i że nie znajdujesz się w sytuacji, w której komunikuje się wiele komputerów ( pamiętaj, że zegary mogą być zsynchronizowane), wtedy jesteś względnie bezpieczny. Ponownie, problemem jest ponowne użycie IV, więc posiadanie dwóch komputerów z tym samym zegarem może prowadzić do statystycznie prawdopodobnych kolizji w tym modelu.

Licznik 1 na 1, wystarczająco duży, aby nie powtórzyć się w, powiedzmy 10-krotności oczekiwanej użyteczności chronionych danych.

Absolutnie w porządku, zakładając, że licznik bierze pod uwagę globalny wymóg unikalności dla dowolnego klucza.

Stała IV

To całkowicie przerywa CBC, jeśli znany jest IV (należy przyjąć, że jest ). Można po prostu zignorować IV dla wszystkich intencji i celów.

IV z zerami

Znowu to psuje CBC, ale tylko dlatego, że jest stałe. Jeśli jest używany tylko raz dla jednej wiadomości na klucz, nadal jest bezpieczny. Treść IV nie jest szczególnie ważna. Po prostu musi być unikalny dla każdego klucza.