Gdy Państwa algorytm już nie wystarcza.

Nie. Aplikacja musi faktycznie stosować odpowiednie algorytmy, wspierać właściwe formaty i być interoperacyjna ze swoimi systemami partnerskimi.

To świadoma decyzja dotycząca ryzyka, podejmowana dla konkretnej usługi. Dokumentujemy takie okresy przejściowe i pokazujemy, które połączenia jeszcze nie osiągają docelowego poziomu.

Trwale wbudowane algorytmy i sztywne formaty danych sprawiają, że każda zmiana jest kosztowna. Analizujemy te powiązania i dostosowujemy oprogramowanie, konfigurację oraz integrację protokołów tak, aby algorytmy kryptograficzne mogły być rozwijane w kontrolowany sposób.

Analiza zakodowanych na stałe algorytmów i założeń dotyczących formatów Uporządkowanie wywołań kryptograficznych i konfiguracji Integracja obsługiwanych bibliotek i dostawców (provider) Sprawdzenie zgodności protokołów i dopuszczonych rozwiązań fallback Przygotowanie testów regresji i kontrolowanego wdrożenia (rollout)

Analiza powiązań kryptograficznych Dostosowana aplikacja lub integracja pilotażowa Plan testów i migracji

Wymienna nazwa algorytmu daje niewiele, jeśli bazy danych oczekują stałej długości podpisu albo klienci nie mogą przetworzyć nowych certyfikatów. Sprawdzamy wywołania, formaty przechowywania, pola protokołów i identyfikatory kluczy. Zadania kryptograficzne są skupiane w odpowiednich bibliotekach i za jasno zdefiniowanymi interfejsami. Nie oznacza to potrzeby tworzenia własnych algorytmów kryptograficznych. Nowe parametry i typy kluczy wymagają kontrolowanego zatwierdzenia, a nie swobodnego wyboru przez użytkownika.

ML-KEM służy do uzgadniania kluczy za pomocą mechanizmu kapsułkowania; ML-DSA i SLH-DSA są algorytmami podpisu. Te zadania nie są wymienne. Konkretna integracja protokołu musi być obsługiwana przez zaangażowane komponenty. Dlatego sprawdzamy odrębnie ustanawianie połączenia, uwierzytelnianie i przechowywane artefakty. W rozwiązaniach hybrydowych klasyczne i postkwantowe elementy są łączone zgodnie z danym protokołem. Dopuszczony klasyczny fallback jest wyraźnie oznaczany, aby możliwe do nawiązania połączenie nie było błędnie uznane za już objęte migracją.

Odbiór wykorzystuje reprezentatywne aplikacje klienckie, bramy i biblioteki. Nieprawidłowe klucze, nieobsługiwane parametry i przestarzałe systemy partnerskie są częścią testów. Formaty danych muszą umożliwiać przejrzyste odwzorowanie późniejszej zmiany. Państwa zespół otrzymuje wprowadzone zmiany, udokumentowane ograniczenia oraz testy regresji. Konkretna wersja oprogramowania jest sprawdzana w ramach projektu, a nie wywodzona ze wsparcia deklarowanego dla całej rodziny produktów.

Analizujemy, gdzie algorytmy, rozmiary kluczy i formaty danych są na stałe wbudowane w Państwa oprogramowanie. Następnie tworzymy odpowiednie granice techniczne, za pomocą których nowe algorytmy można wprowadzać w sposób kontrolowany.

Stałe założenia dotyczące algorytmów i formatów zostały zidentyfikowane. Stare i nowe wersje danych są jednoznacznie rozróżniane. Niedopuszczalne powroty do starszych algorytmów i kombinacje są wychwytywane w testach.

Przykład: aplikacja przechowuje podpisy w polu o z góry ustalonej długości. Usuwamy to powiązanie, wersjonujemy format i sprawdzamy generowanie oraz weryfikację starych i nowych rekordów. Faktyczna zmiana algorytmu kryptograficznego następuje dopiero po potwierdzeniu, że obsługuje ją cały łańcuch przetwarzania.

Sztywno zakodowane założenia można znaleźć nie tylko w samym wywołaniu funkcji kryptograficznej. Pola bazy danych, formaty plików i interfejsy mogą wymagać ustalonej długości lub konkretnego typu klucza. Sprawdzamy te miejsca wspólnie z bibliotekami i konfiguracją, aby zmiana nie zakończyła się niepowodzeniem z powodu pozornie niezwiązanego z nią pola danych. Abstrakcja nie oznacza tworzenia własnej biblioteki kryptograficznej. Sprawdzone implementacje są integrowane za pomocą zrozumiałego interfejsu. Dopuszczalne algorytmy i parametry pozostają pod kontrolą; dowolny wybór na podstawie niezaufanych danych wejściowych nie może zastępować decyzji dotyczącej bezpieczeństwa.

Istniejące dane lub partnerzy komunikacyjni mogą wciąż potrzebować starszych algorytmów. Projektujemy rozpoznawalne wersjonowanie i sprawdzamy, które równoległe stany eksploatacyjne są faktycznie wspierane. Powrót do starszego algorytmu nie może zostać wywołany w sposób niezauważony przez atakującego lub przez błędnie działający system partnerski. Dla każdej wspieranej kombinacji ustalane są testy i kryteria zatwierdzenia. Algorytmy, które nie są już dopuszczone, muszą dać się celowo wyłączyć. W ten sposób elastyczność kryptograficzna staje się utrzymywanym procesem zmian z udokumentowanymi granicami, a nie niekontrolowaną zbieraniną opcji.

Inwentarz kryptograficzny i potrzeby ochrony IT, bezpieczeństwo informacji, właściciele aplikacji, specjalista ds. kryptografii OTOKO® CBOM, potrzeby ochrony i czas życia danych dla każdego systemu, analiza luk względem BSI TR-02102

Mapa drogowa, docelowe algorytmy, fazy przejściowe Architektura, bezpieczeństwo informacji, eksploatacja PKI, zakupy Mapa drogowa migracji, polityka kryptograficzna, docelowy model PKI i HSM, model eksploatacji