# Inwentaryzacja kryptografii z ruchu sieciowego

> Jaką część inwentaryzacji kryptografii (CBOM) da się zbudować pasywnie z handshake'ów TLS i SSH, czego nie widać i jak uzupełnić luki.

Source page: https://netsenx.com/pl/blog/2026-11-12_cryptographic-inventory-from-network-traffic · NetSenX Team · 2026-11-12

Dużą część inwentaryzacji kryptografii można zbudować pasywnie, odczytując handshake'i, które przechodzą przez sieć: jakich wersji TLS i SSH używa każdy serwer i klient, jakie grupy wymiany kluczy oferują i uzgadniają, jakie zestawy szyfrów, a tam, gdzie handshake je pokazuje, jakie algorytmy klucza publicznego i długości kluczy. Nie widać kryptografii, która nigdy nie przechodzi przez monitorowane łącze. Widok z sieci jest więc najszybszym sposobem, żeby objąć każde urządzenie, także te, których nikt nie spisał, i trzeba go uzupełnić inwentaryzacją certyfikatów i odpowiedziami dostawców. Każda postkwantowa mapa drogowa, zaczynając od unijnej, stawia tę inwentaryzację na pierwszym miejscu.

## Co zawiera inwentaryzacja kryptografii

Użyteczna inwentaryzacja odpowiada dla każdego systemu: jakimi protokołami i wersjami się posługuje, jakich algorytmów wymiany kluczy i podpisu używa i o jakich długościach kluczy, jakie ma certyfikaty i kto je wydał, która biblioteka lub produkt dostarcza kryptografię, kto odpowiada za system i jak długo dane, które chroni, muszą pozostać tajne. Opublikowana w formie czytelnej dla maszyn nazywana jest często CBOM (cryptography bill of materials); taki format definiuje standard CycloneDX. Nie chodzi o sam dokument, tylko o decyzje, które umożliwia: co migrować najpierw i o co pytać którego dostawcę.

## Co pokazuje sieć bez odszyfrowywania

- **Wersje protokołów.** TLS 1.0 i 1.1, SSH 1 i inne przestarzałe wersje widać na początku każdego połączenia.
- **Oferowana i wybrana wymiana kluczy.** W TLS 1.3 ClientHello wymienia obsługiwane przez klienta grupy i udziały kluczy, a ServerHello podaje grupę wybraną przez serwer. Widać więc wprost, czy połączenie użyło grupy klasycznej, takiej jak X25519 czy P-256, czy hybrydowej postkwantowej X25519MLKEM768. SSH w ten sam sposób jawnie ogłasza swoje metody wymiany kluczy.
- **Zestawy szyfrów.** Szyfr symetryczny i funkcja skrótu, na które umawia się każde połączenie, co ujawnia pozostałości takie jak 3DES czy RC4.
- **Klucze i certyfikaty tam, gdzie idą jawnie.** W TLS 1.2 łańcuch certyfikatów serwera jest wysyłany bez szyfrowania, więc widać jego algorytm podpisu i długość klucza. Klucze hosta SSH są wymieniane jawnie. W TLS 1.3 certyfikat jest zaszyfrowany, więc dla takich serwerów potrzebny jest skan albo inwentaryzacja certyfikatów.
- **Słabe klucze.** Klucze publiczne zebrane z handshake'ów można porównać między sobą. Klucze RSA, które mają wspólny czynnik pierwszy, są po prostu złamane i są klasycznym śladem urządzenia ze słabym generatorem liczb losowych, zwykle urządzenia sieciowego albo systemu wbudowanego.
- **Każde urządzenie w segmencie.** Drukarki, kamery, bramy OT, urządzenia sieciowe i stare serwery są objęte tak samo jak zarządzane laptopy, czyli tam, gdzie narzędzia oparte na agentach są ślepe.

## Czego nie widać

- Kryptografii wewnątrz aplikacji i baz danych, na przykład szyfrowania pól albo wywołania biblioteki we własnym kodzie.
- Kluczy i certyfikatów zapisanych na dyskach, w magazynach kluczy albo w modułach HSM.
- Podpisywania kodu i aktualizacji oprogramowania, chyba że sprawdzasz sam kanał aktualizacji.
- Zaszyfrowanych kopii zapasowych i archiwów.
- Ruchu w segmentach, których nie obserwuje żaden czujnik, i połączeń, które nigdy nie przechodzą przez monitorowane łącze.
- Certyfikatu w większości połączeń TLS 1.3, jak wspomniano wyżej.

## Jak uzupełnić luki

Połącz widok z sieci z trzema innymi źródłami: inwentaryzacją certyfikatów z urzędu certyfikacji, narzędzi zarządzania albo aktywnego skanu; wykazami komponentów oprogramowania (SBOM) i dokumentacją dostawców używanych produktów; oraz ankietami dla dostawców z pytaniem, z datami, kiedy każdy produkt będzie obsługiwał hybrydową postkwantową wymianę kluczy i podpisy postkwantowe. Potem uszereguj systemy według nierówności Moski, jak wyjaśnia [przewodnik po kryptografii postkwantowej](/pl/blog/2026-11-12_post-quantum-readiness-guide), i powtarzaj pomiar w sieci po każdej zmianie, żeby potwierdzić, że zadziałała.

## Gdzie pasuje NetSenX

To właśnie robi NQCI, inwentaryzacja kryptografii NetSenX. Jest w wersji zapoznawczej, widoczna w każdym planie i aktywna od planu Pro, z włączonym czujnikiem przechwytywania pakietów na agencie Linux albo czujnikiem na porcie SPAN lub TAP; podstawowy tryb macOS nie widzi handshake'ów. Pokazuje, które połączenia w monitorowanym ruchu używają wymiany kluczy podatnej na komputery kwantowe, a które już hybrydowej postkwantowej, oznacza słabe klucze publiczne i zapisuje zmiany w czasie. Nie zmienia żadnej kryptografii i nikomu nie zapewnia zgodności; pokazuje, w jakim miejscu jesteś.

## Źródła

- [RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 — IETF](https://www.rfc-editor.org/rfc/rfc8446)
- [RFC 4253, The Secure Shell (SSH) Transport Layer Protocol — IETF](https://www.rfc-editor.org/rfc/rfc4253)
- [CycloneDX Cryptography Bill of Materials (CBOM)](https://cyclonedx.org/capabilities/cbom/)
- [Heninger i in., Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices, USENIX Security 2012](https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger)

---

*Autor: zespół NetSenX, TriStiX S.L. Pytania: [info@netsenx.com](mailto:info@netsenx.com).*