PQC · crypto agility
Przygotuj produkty i systemy do zmiany kryptografii
Zacznij od wiedzy, gdzie używasz kryptografii, co chroni i jak można ją aktualizować. Pomagamy przełożyć tę wiedzę na ocenę wykonalności, plan migracji i dowody testów.
Dwie powiązane potrzeby
PQC — kryptografia postkwantowa
Mechanizmy kryptograficzne projektowane z myślą o odporności na ataki z użyciem komputerów kwantowych. Migracja wymaga oceny zastosowań, protokołów i zależności.
Crypto agility — zdolność zmiany
Możliwość bezpiecznej zmiany algorytmów, protokołów, kluczy i ich zastosowań w produktach oraz systemach. Obejmuje architekturę, procesy, aktualizacje i współpracę z dostawcami.
Dla urządzeń embedded i OT szczególnie ważne są długi czas eksploatacji, ograniczone zasoby, podpisy firmware oraz zgodność z istniejącą infrastrukturą. Ten sam sposób pracy pomaga reagować na kompromitację klucza, koniec wsparcia biblioteki czy zmianę dostawcy.
Profil konkretnej konfiguracji produktu
Jednostką analizy jest zastosowanie kryptografii w dokładnie wskazanej konfiguracji: np. rodzinie produktu, rewizji sprzętu, bootloaderze i wersji firmware. Dzięki temu ocena jednego wariantu nie zastępuje sprawdzenia pozostałych.
- Funkcja: bezpieczny rozruch, podpis aktualizacji, komunikacja, tożsamość urządzenia lub ochrona przechowywanych danych.
- Implementacja: algorytm i parametry, biblioteka lub dostawca, protokół oraz zależności od sprzętu.
- Zaufanie: odniesienia do kluczy, certyfikatów i źródeł zaufania oraz możliwość ich wymiany i unieważniania.
- Podstawa oceny: dokumentacja, konfiguracja, kod, SBOM lub inwentarz kryptografii i wyniki testów; z zaznaczeniem pochodzenia informacji i braków.
Rozróżniamy potwierdzone działanie, warunkową możliwość i niewiadome. Sama obecność algorytmu w bibliotece nie dowodzi, że urządzenie go używa ani że potrafi bezpiecznie przejść na nowy mechanizm.
Czy zmianę da się bezpiecznie wykonać?
Wykonalność aktualizacji i granice sprzętowe
Sprawdzamy, co można zmienić programowo, a co ogranicza ROM, bootloader lub komponent bez aktualizacji. Uwzględniamy możliwość odzyskania urządzenia po przerwaniu zmiany.
Zasoby i kompatybilność
Oceniamy czas operacji, pamięć, rozmiar komunikatów i obrazów firmware oraz współpracę ze starszymi urządzeniami, backendem i narzędziami serwisowymi.
Przejście między źródłami zaufania
Ustalamy kolejność dostarczenia nowego weryfikatora i zaufania, zmiany systemu podpisującego oraz wycofania starych kluczy. Warunki trzeba sprawdzić na docelowym sprzęcie.
Wynik oceny wskazuje możliwości potwierdzone, warunkowe, zablokowane lub nieustalone, wraz z uzasadnieniem i kolejnym działaniem. Nie sprowadzamy krytycznych ograniczeń do jednego procentowego wyniku gotowości.
Trzy osobne ścieżki migracji
Komunikacja
Zmiana TLS lub innego protokołu wymaga sprawdzenia obu stron połączenia, negocjacji mechanizmów, opóźnień i interoperacyjności. Brama pośrednicząca może chronić jedynie wybrany odcinek komunikacji.
Podpisy aktualizacji
Potrzebny jest zgodny system podpisujący i weryfikacja w urządzeniu, bezpieczna dystrybucja zaufania oraz procedura odzyskiwania. Testujemy również odrzucenie nieautoryzowanego obrazu i niedozwolonego cofnięcia wersji.
Bezpieczny rozruch
Łańcuch ROM → bootloader → firmware może zawierać mechanizmy niepodlegające aktualizacji. Sprawdzamy granice sprzętowe oraz to, czy zmiana wymaga innego wariantu urządzenia.
Zmiana ochrony komunikacji nie oznacza migracji podpisów firmware ani bezpiecznego rozruchu. Każdą ścieżkę oceniamy osobno i łączymy dopiero w planie dla konkretnej konfiguracji.
Od inwentarza do sprawdzonej zmiany
- Zakres i inwentarz: wybór rodziny produktu, rewizji sprzętu oraz wersji firmware; zebranie zastosowań kryptografii i dowodów.
- Ocena wykonalności: ograniczenia aktualizacji, zasobów i zależności; porównanie zmiany natywnej, adaptera lub wymiany sprzętu.
- Plan migracji: kolejność zmian, warunki przejścia zaufania, odpowiedzialności i kryteria akceptacji.
- Pilotaż i testy: uzgodniony scenariusz na rzeczywistym urządzeniu, interoperacyjność, zużycie zasobów i zachowanie po przerwaniu aktualizacji.
- Decyzja i utrzymanie: dowody przypisane do konfiguracji, warunki wydania i lista ocen do ponowienia po zmianie.
Rezultatem jest inwentarz z poziomem pewności, ocena wykonalności, plan migracji i uporządkowane dowody testów. Zakres wybieramy według decyzji, którą ma podjąć zespół.
Propozycja pilotażu: jeden produkt, jedna zmiana
Przykładowy zakres do uzgodnienia: jeden produkt IoT lub OT, jedna rewizja sprzętu, dwie wersje firmware i jeden scenariusz zmiany kryptografii, sprawdzony na rzeczywistym urządzeniu.
Może to być przejście na nowy mechanizm ochrony komunikacji albo zmiana podpisów aktualizacji. Najpierw ustalamy dostęp do urządzenia, dokumentacji i środowiska testowego oraz mierzalne kryteria.
- Profil kryptografii i jawne braki informacji dla obu wersji.
- Porównanie możliwych ścieżek zmiany wraz z ich ograniczeniami.
- Plan z kolejnością, warunkami, odpowiedzialnościami i procedurą odzyskiwania.
- Wyniki testów przejścia zaufania, przerwania aktualizacji i zużycia zasobów — odpowiednio do wybranego scenariusza.
- Pakiet dowodów i przegląd wpływu zmiany na dokumentację oraz decyzję o wydaniu.
To propozycja współpracy i prac B+R, a nie opis zakończonego wdrożenia ani gotowego produktu. Integrację, terminy i zasoby uzgadniamy indywidualnie.
Standardy są punktem wyjścia
NIST opublikował standardy ML-KEM / FIPS 203 dla ustanawiania wspólnego sekretu oraz ML-DSA / FIPS 204 i SLH-DSA / FIPS 205 dla podpisów cyfrowych.
Aktualne informacje: NIST — Post-Quantum Cryptography. Dobór mechanizmu zależy od funkcji, protokołu, implementacji i ograniczeń produktu.
Samo zastosowanie algorytmu PQC nie oznacza certyfikacji produktu ani zgodności z CRA. Plan migracji łączymy z oceną ryzyka i sposobem utrzymania konkretnego systemu.
Wspólny temat dla produktów i OT
W projekcie CRA kryptografia jest częścią architektury i okresu wsparcia. W środowisku OT zmiana musi uwzględniać ciągłość procesu oraz możliwości dostawców.
Producent rozstrzyga gotowość wersji produktu, a operator — warunki wdrożenia w konkretnej instalacji. Pomagamy uporządkować informacje potrzebne obu stronom, w tym wspierane konfiguracje, ograniczenia i wymagania aktualizacji.
CRA i cykl życia produktu · Cyberbezpieczeństwo OT · Szkolenia i warsztaty
Materiały i dalsza rozmowa
nis2cra.com
Materiały, analizy, kwalifikatory i inicjatywy dotyczące NIS2, CRA oraz cyberbezpieczeństwa OT.
cratrace.com
cratrace — projekt związany z zarządzaniem informacjami i dowodami w cyklu życia produktu w kontekście wymagań CRA.
Omówmy gotowość kryptograficzną
Napisz, jaki produkt lub system analizujesz, jak długo ma działać i jaka zmiana jest przed Tobą. Nie musisz mieć gotowego inwentarza.