AES-NI
AES-NI to rozszerzenie instrukcji x86 dla rund szyfrowania i deszyfrowania AES oraz powiązanych operacji harmonogramowania klucza (key schedule). Przyspiesza ono fragmenty implementacji kryptograficznej, zamiast zapewniać kompletny bezpieczny protokół.
Co musisz wiedzieć
AES-NI to rozszerzenie instrukcji x86 dla rund szyfrowania i deszyfrowania AES oraz powiązanych operacji harmonogramowania klucza (key schedule). Przyspiesza ono fragmenty implementacji kryptograficznej, zamiast zapewniać kompletny bezpieczny protokół.
Jak to działa
Instrukcje takie jak AESENC i AESDEC przekształcają 128-bitowy stan AES, podczas gdy osobne formy obsługują rundy końcowe i wspomagają rozszerzanie klucza. Implementacja AES dobiera liczbę oraz kolejność rund zależnie od długości klucza. Same instrukcje nie wybierają trybu, nie przydzielają wektorów inicjalizacyjnych (nonce), nie uwierzytelniają wiadomości ani nie chronią przechowywanych kluczy.
Gdzie funkcja jest przydatna
Utrzymywana biblioteka kryptograficzna może kierować operacje do AES-NI w przypadku obsługiwanego trybu AES. AES-GCM wymaga również przetwarzania uwierzytelniania, często przyspieszanego za pomocą mnożenia bezprzeniesieniowego. Negocjacja protokołu, układ rekordów i długość wiadomości wpływają na wydajność całego procesu (end-to-end).
Jak sprawdzać obsługę i włączenie
CPUID.01H:ECX bit 25 wskazuje na klasyczne AES-NI. Środowisko wykonawcze musi zarządzać stanem XMM. Wymagania dotyczące VAES i stanu wektorowego należy sprawdzać osobno dla szerszych implementacji VEX lub EVEX, korzystając z obsługiwanych przez bibliotekę kryptograficzną mechanizmów dispatch.
Należy korzystać z utrzymywanej implementacji kryptograficznej, która odpowiada za wybór funkcji, obsługę błędów i kompletny algorytm. Akceleracja sprzętowa dostarcza operacje elementarne; zarządzanie kluczami, uwierzytelnianie, reguły dotyczące nonce oraz wybór protokołu pozostają po stronie oprogramowania.
Czego ta funkcja nie określa
Obsługa AES-NI nie stanowi certyfikatu bezpieczeństwa, oceny braku złośliwego oprogramowania ani gwarancji ochrony przed kanałami bocznymi w otaczającym kodzie. AES to nie SHA. VAES jest sprawdzane osobnym bitem, a system-gość może mieć ukryte AES-NI nawet wtedy, gdy host je posiada.
Zgodność i wydajność w praktyce
Pole funkcji nie jest certyfikacją produktu ani dowodem na to, że dana aplikacja jest bezpieczna. Wydajność zależy od wielkości wiadomości, trybu, grupowania zadań (batching) i pozostałych elementów protokołu. Należy zweryfikować faktycznego dostawcę i dbać o aktualność jego poprawek bezpieczeństwa.
Praktyczna lista kontrolna weryfikacji
- Zanotuj dokładny model procesora lub platformy oraz wersje używanej aplikacji, systemu operacyjnego i środowiska wykonawczego. Zachowaj dokładne sformułowanie błędu lub wymagania.
- Sprawdź dokumentację producenta dla danego modelu, a następnie zweryfikuj faktyczne możliwości i stan włączenia w środowisku, w którym działa program.
- Porównaj każde wymaganie wybranego pliku binarnego lub backendu. Podobnie nazwana funkcja, alias lub ogólne oznaczenie technologii nie są wystarczające.
- Upewnij się, że aplikacja wybrała zamierzoną implementację. Użyj jej udokumentowanej diagnostyki oraz obsługiwanego mechanizmu fallback, gdy wymagania nie są spełnione.
- Wprowadzaj jednorazowo tylko jedną obsługiwaną zmianę i powtarzaj to samo obciążenie testowe. Zachowaj oryginalną konfigurację oraz dostępną ścieżkę przywracania.
Gdy funkcja jest wymieniona, lecz oprogramowanie nie może z niej skorzystać
Zacznij od elementu, w którym bezpośrednio występuje błąd. Baza danych sprzętu opisuje zarejestrowane możliwości; system operacyjny lub hipernadzorca może udostępniać inne środowisko efektywne. Błąd nieprawidłowej instrukcji (illegal instruction) wymaga także zbadania faktycznej instrukcji powodującej błąd oraz kompilacji pliku binarnego, ponieważ uszkodzenie danych lub inna nieobsługiwana instrukcja może wywołać podobny objaw.
Zainstaluj wersję aplikacji, sterownika lub środowiska wykonawczego obsługiwaną na danej platformie i w razie potrzeby użyj udokumentowanej przez producenta kompilacji bazowej lub awaryjnej. Aktualizacja oprogramowania nie może utworzyć instrukcji, której procesor fizycznie nie posiada. Modyfikacje oprogramowania układowego i zasad bezpieczeństwa powinny przebiegać zgodnie z procedurą producenta systemu i planem przywracania, a nie ogólnikowym schematem optymalizacji.
Źródła i zakres niniejszego opisu
Intel 64 and IA-32 Architectures Software Developer's Manual
Te źródła definiują zachowanie architektoniczne i wymagania oprogramowania. Nie weryfikują one niezależnie każdej wartości funkcji na powiązanej stronie modelu sprzętu. W celu sprawdzenia obsługi przez model należy skorzystać z materiałów producenta na tej stronie i sprawdzić efektywną konfigurację systemu. Niniejszy artykuł nie zawiera wyników testów wydajnościowych, certyfikacji ani daty niezależnego przeglądu.
Źródła i weryfikacja
Własność redakcyjna: Feex. Nie odnotowano daty niezależnego przeglądu. Jak prowadzimy badania.
- Intel 64 and IA-32 Architectures Software Developer's Manual · Tomy 1 i 2 opisują wymienione rodziny instrukcji oraz CPUID; tom 3 opisuje stan, stronicowanie, VMX i mechanizmy ochrony. Dokumentacja architektury nie przesądza o obsłudze w konkretnym modelu.
Czy ten artykuł był pomocny?
Wystarczy odpowiedź tak lub nie. Wybierz powód, jeśli chcesz, lub dodaj krótką notatkę.
Dziękujemy. Pomaga nam to ulepszać tę stronę.