Dlaczego Encrypt-Then-MAC jest lepsze niż MAC-Then-Encrypt

Podczas łączenia szyfrowania z kodem MAC istnieją trzy kolejności: Encrypt-then-MAC (EtM), MAC-then-Encrypt (MtE) oraz Encrypt-and-MAC (E&M). Każda z nich ma zasadniczo inne właściwości bezpieczeństwa, a tylko jedna jest dowiedzenie bezpieczna we wszystkich ustawieniach.

W Encrypt-then-MAC tekst jawny jest najpierw szyfrowany w celu uzyskania szyfrogramu, a następnie kod MAC jest obliczany na podstawie tego szyfrogramu. Odbiorca może zweryfikować MAC, zanim w ogóle podejmie próbę odszyfrowania, dzięki czemu zmodyfikowana wiadomość zostaje natychmiast odrzucona bez ujawniania informacji.

W MAC-then-Encrypt kod MAC jest obliczany na podstawie tekstu jawnego, a następnie tekst jawny i MAC są wspólnie szyfrowane. Odbiorca musi odszyfrować wiadomość, zanim będzie mógł zweryfikować MAC, co otwiera drogę do ataków typu padding oracle i decryption oracle.

SSL 3.0 i TLS 1.0 stosowały kolejność MAC-then-Encrypt dla szyfrów blokowych w trybie CBC. Ta wada projektowa została wykorzystana przez atak BEAST w 2011 roku i atak POODLE w 2014 roku; oba ataki wykorzystywały wyrocznię istniejącą wtedy, gdy odszyfrowanie następuje przed weryfikacją MAC.

W 2000 roku Bellare i Namprempre formalnie dowiedli, że spośród trzech kolejności tylko Encrypt-then-MAC zapewnia bezpieczeństwo IND-CCA2 (bezpieczeństwo wobec ataków z wybranym szyfrogramem) dla wszystkich kombinacji bezpiecznych prymitywów szyfrowania i MAC. MtE i E&M mogą zawodzić w przypadku niektórych połączeń.

SSH używa Encrypt-and-MAC: kod MAC jest obliczany na podstawie tekstu jawnego i wysyłany obok szyfrogramu w postaci jawnej. Chociaż SSH nie padło ofiarą takich samych exploitów jak MtE w SSL/TLS, to połączenie również jest wadliwe z teoretycznego punktu widzenia, ponieważ może ujawniać informacje o tekście jawnym za pośrednictwem niezaszyfrowanego MAC.

Authenticated Encryption with Associated Data (AEAD) to nowoczesna abstrakcja, która z założenia rozwiązuje problem łączenia. AEAD integruje szyfrowanie i uwierzytelnianie w jednym prymitywie, zapewniając ich prawidłowe połączenie bez konieczności wybierania przez programistę kolejności łączenia.

AES-GCM (Galois/Counter Mode) to najczęściej wdrażany zestaw szyfrów AEAD. Zapewnia szyfrowanie uwierzytelnione dzięki połączeniu szyfrowania w trybie CTR z uwierzytelnianiem GHASH i jest przyspieszany sprzętowo za pomocą instrukcji AES-NI i CLMUL we współczesnych procesorach.

TLS 1.3 zdecydowanie odcięło się od przeszłości, usuwając wszystkie zestawy szyfrów inne niż AEAD. Każdy zestaw szyfrów TLS 1.3 używa AEAD, eliminując całe klasy luk powodowanych przez nieprawidłowe, ręczne łączenie prymitywów szyfrowania i MAC, które nękały wcześniejsze wersje TLS.

Najważniejsza lekcja płynąca z dziesięcioleci ataków kryptograficznych jest taka, że ręczne łączenie prymitywów szyfrowania i MAC prowadzi do błędów nawet w przypadku ekspertów. Nowoczesne biblioteki kryptograficzne udostępniają interfejsy AEAD właśnie po to, aby uniemożliwić programistom popełnianie błędów podczas łączenia, które prowadzą do rzeczywistych luk w zabezpieczeniach.

Podczas tworzenia systemów należy zawsze wybierać prymityw AEAD, taki jak AES-GCM lub ChaCha20-Poly1305. Jeśli konieczna jest współpraca ze starszymi systemami używającymi oddzielnego MAC i szyfrowania, należy upewnić się, że stosowana jest kolejność Encrypt-then-MAC, a nigdy MtE ani E&M.

EtM jest jedyną dowiedzenie bezpieczną kolejnością łączenia oddzielnych prymitywów szyfrowania i MAC. TLS 1.3 całkowicie eliminuje ten problem, wymagając zestawów szyfrów korzystających wyłącznie z AEAD. W razie wątpliwości należy użyć prymitywu AEAD, takiego jak AES-GCM lub ChaCha20-Poly1305, i pozwolić bibliotece prawidłowo obsłużyć łączenie.