Następnie szyfruj MAC w protokole SIGMA dla uwierzytelnionej wymiany kluczy
Protokół SIGMA zaproponowany w 2003 roku i stosowane w TLS 1.3 i IKE oznacza „Sign-i-Mac” i może ewentualnie ochronie tożsamości za pomocą szyfrowania.
Wariant SIGMA-I zilustrowany poniżej wskazuje, że wykorzystuje podejście MAC-następnie-szyfrowania:

Tutaj $\{\dots \}_{K} $ oznacza szyfrowanie informacji między nawiasami w ramach symetrycznej funkcji szyfrowania za pomocą klucza $K$.
Czy jest jakiś szczególny powód, aby używać MAC-then-encrypt zamiast szyfrowania-then-MAC dla protokołów wymiany kluczy? Nie byłem w stanie znaleźć lepszej odpowiedzi, niż wydaje się to arbitralne, patrząc na porównanie między MAC-następnie-zaszyfruj i zaszyfruj-wtedy-MAC .
Edycja: RFC 7366 powiązany w tej powiązanej odpowiedzi daje pewne wskazówki, że szyfrowanie-to-MAC powinno być preferowane (D) komunikacja TLS (nie mówi się o uzgadnianiu). W szczególności stwierdza:
TLS i DTLS wykorzystują konstrukcję MAC-then-encrypt, która była uważana za bezpieczną w czasie, gdy pierwotny protokół Secure Socket Layer (SSL) został określony w połowie lat 90., ale nie jest już uważany za bezpieczny.
Co ciekawe, H Krawczyk (autor SIGMA) napisał w 2001 r. The Order of Encryption and Authentication for Protecting Communications (czyli: How Secure Is SSL?) —Przed SIGMA.
Odpowiedzi
Arnaud poprosił mnie o wyjaśnienie tej kwestii.
Prawdą jest, że należy użyć uwierzytelnionego trybu szyfrowania lub zaszyfrować-to-MAC, a artykuł wyraźnie to mówi. Rzeczywiście, tekst wyjaśniający w artykule następujący po rysunku przedstawionym powyżej (sekcja 5.2 zhttps://webee.technion.ac.il/~hugo/sigma-pdf.pdf) rozwiązuje ten problem. To mówi:
Podkreślamy, że funkcja szyfrowania (zastosowana w trzeciej wiadomości) musi być odporna na aktywne ataki i dlatego musi łączyć jakąś formę ochrony integralności. Można zastosować połączone transformacje poufności i integralności, takie jak te z [16], lub konwencjonalny tryb szyfrowania (np. CBC) z funkcją MAC obliczaną na zaszyfrowanym tekście [3, 26].
Mianowicie oznaczone szyfrowanie $\{...\}_{K_e}$musi używać uwierzytelnionego schematu szyfrowania. (Potrzeba uwierzytelnionego szyfrowania jest również powtórzona w dodatku B, który przedstawia bardziej kompletny protokół w postaci SIGMA-R).
Fakt, że pod szyfrowaniem znajduje się adres MAC (na tożsamości), wynika z tego, że MAC jest (istotną) częścią protokołu SIGMA i jest całkowicie niezwiązany z szyfrowaniem (w szczególności potrzebny, nawet jeśli nie zależy Ci na ochronie tożsamości ). Tak więc, chociaż wygląda to na „szyfrowanie MAC-następnie”, nie ma to żadnego związku z tym trybem szyfrowania.
Uwaga: powodem, dla którego tekst mówi, że uwierzytelnione szyfrowanie jest potrzebne tylko w przypadku trzeciej wiadomości, jest to, że, jak wspomniano na początku tego samego akapitu, SIGMA-I chroni tożsamość inicjatora przed aktywnymi atakującymi, a tożsamość odpowiadającego przed pasywnym napastników. Dlatego szyfrowanie tożsamości osoby odpowiadającej wymaga tylko zabezpieczenia przed pasywnymi atakami, do których wystarczy nieuwierzytelnione szyfrowanie. To naprawdę akademicka uwaga, ponieważ w praktyce należałoby użyć tego samego schematu szyfrowania dla obu przepływów, a mianowicie uwierzytelnionego szyfrowania dla obu.
To trochę spekulacja, ale przypuszczam, że wynika to z modułowego sposobu, w jaki zaprojektowano Sigmę. Mianowicie, kiedy Hugo Krawczyk projektował Sigmę, głównym zabezpieczeniem, o które zabiegał, była ochrona AKE, która w zasadzie składa się z dwóch rzeczy:
Nierozróżnialność klucza sesji: przeciwnik nie powinien być w stanie odróżnić prawdziwych kluczy sesji od losowych; i
Jawne uwierzytelnianie jednostki (EA): właściwość, która mówi, że gdy uczestnik protokołu zakończy przebieg protokołu, gwarantuje się, że faktycznie komunikuje się z oczekiwaną stroną i że ta strona rzeczywiście obliczyła ten sam klucz sesji.
Właściwość EA jest w zasadzie kluczowym krokiem potwierdzającym, który zapewnia żywotność i uwierzytelnianie. Osiąga się to poprzez obliczenie MAC na podstawie niektórych danych protokołu przy użyciu klucza$K_m$ pochodzi z tego samego klucza głównego, który został użyty do wyprowadzenia klucza sesji.
Chodzi o to, że możesz osiągnąć bezpieczeństwo AKE (czyli właściwość 1 i 2) bez żadnego szyfrowania! Rzeczywiście, kiedy Krawczyk udowodni, że Sigma spełnia zabezpieczenia AKE (nie pamiętam, który to był papier; spróbuje go później znaleźć), po prostu zakłada, że etapu szyfrowania w ogóle nie ma! (Robi to również w swoim artykule OPTLS, który jest prekursorem TLSv1.3).
Jak powiedziałem, standardowym celem bezpieczeństwa dla większości protokołów wymiany kluczy było, od czasu oryginalnych artykułów Bellare i Rogaway , w zasadzie wszystko o bezpieczeństwie AKE. Projektując Sigmę Krawczyk chciał jednak dodać jeszcze jedną, niestandardową cechę, a mianowicie ochronę tożsamości . Ale biorąc pod uwagę, że już pokazał, że protokół Sigma bez szyfrowania zapewnił bezpieczeństwo AKE, po prostu dodano do tego szyfrowanie, aby również uzyskać ochronę tożsamości. Zatem: MAC-then-Encrypt.
Należy jednak zauważyć, że te dwa zastosowania MAC i szyfrowania są raczej ortogonalne i służą różnym celom: wewnętrzny MAC ma zapewniać bezpieczeństwo EA, podczas gdy zewnętrzne szyfrowanie ma zapewniać ochronę tożsamości.
Należy również pamiętać, że Sigma zazwyczaj nie używać Szyfrowanie-then-Mac. W szczególności w przypadku instancji Sigmy w IKEv2 zewnętrznemu szyfrowaniu towarzyszy dodatkowy adres MAC poza szyfrowaniem w sposób standardowy EtM. W IKEv2 wywoływany jest wewnętrzny klucz MAC, wywoływany jest SK_p*
zewnętrzny klucz szyfrujący SK_e*
i zewnętrzny klucz MAC SK_a*
( *
jest to i
albo w r
zależności od tego, czy wiadomość jest tworzona przez inicjatora, czy przez osobę odpowiadającą). Ponadto w nowszych instancjach IKEv2 zewnętrzne szyfrowanie jest zastępowane przez dedykowane uwierzytelnione algorytmy szyfrowania. W tym przypadku SK_a*
klucze nie są używane (i cała kwestia EtM staje się dyskusyjna). W instancji Sigmy TLSv1.3 używane jest tylko uwierzytelnione szyfrowanie. Ale znowu zwróć uwagę, że wewnątrz szyfrowania (czy to AE, czy EtM) znajduje się wewnętrzny adres MAC, którego celem jest zapewnienie bezpieczeństwa EA.