CoAP - protokół IoT dla urządzeń o ograniczonych zasobach

CoAP (Constrained Application Protocol) to protokół warstwy aplikacji zaprojektowany specjalnie dla urządzeń o ograniczonych zasobach obliczeniowych, pamięci i energii - mikrokontrolerów z kilkoma kilobajtami RAM, czujników zasilanych bateryjnie i sieci o niskiej przepustowości (6LoWPAN, NB-IoT, LoRaWAN). Zdefiniowany w RFC 7252 (2014) przez IETF, CoAP można opisać jako “HTTP dla IoT” - implementuje model RESTful (GET, PUT, POST, DELETE) nad UDP zamiast TCP, dzięki czemu wymaga minimalnych zasobów i radzi sobie z sieciami o dużej utracie pakietów.

CoAP jest szeroko stosowany w systemach smart city, monitoringu środowiskowym, inteligentnych budynkach i sieciach czujników przemysłowych - wszędzie tam, gdzie HTTP i TCP są zbyt ciężkie dla urządzeń końcowych.

Architektura protokołu

CoAP działa w modelu klient-serwer (jak HTTP), ale z istotnymi różnicami wynikającymi z ograniczeń środowiska docelowego:

Parametr	CoAP	CoAP over DTLS
Transport	UDP	UDP + DTLS 1.2/1.3
Port	5683	5684
Uwierzytelnianie	Brak natywnego	PSK, certyfikaty X.509, RPK
Szyfrowanie	Brak	AES-CCM-128 (DTLS)
Model komunikacji	Request/response + observe	Jak obok
Rozmiar nagłówka	4 bajty (kompaktowy binarny)	+ narzut DTLS
Odkrywanie zasobów	/.well-known/core (RFC 6690)	Jak obok

Kluczowe cechy CoAP:

• Observe (RFC 7641) - klient rejestruje się na powiadomienia o zmianach zasobu, eliminując konieczność pollingu. Serwer wysyła aktualizacje gdy wartość się zmieni
• Block-wise transfer (RFC 7959) - przesyłanie dużych payloadów w blokach, konieczne przy ograniczonym MTU sieci 6LoWPAN (127 bajtów na ramkę IEEE 802.15.4)
• Resource discovery - endpoint /.well-known/core zwraca listę wszystkich zasobów urządzenia w formacie CoRE Link Format
• Proxy i cache - CoAP wspiera proxy HTTP-CoAP, umożliwiając integrację urządzeń IoT z infrastrukturą webową

Zastosowania

CoAP znajduje zastosowanie przede wszystkim w środowiskach, gdzie HTTP/TCP nie jest opcją:

• Sieci czujników 6LoWPAN/Thread - monitoring temperatury, wilgotności, jakości powietrza w budynkach i halach produkcyjnych
• Smart metering - odczyt inteligentnych liczników przez NB-IoT z minimalnym zużyciem energii
• Automatyka budynkowa - sterowanie oświetleniem i HVAC przez protokoły mesh (Thread, Zigbee z bramką CoAP)
• Monitorowanie aktywów przemysłowych - czujniki wibracji i temperatury na maszynach, raportujące przez CoAP do bramki IoT

Ocena bezpieczeństwa

CoAP sam w sobie nie zapewnia bezpieczeństwa - DTLS jest opcjonalny i w praktyce często pomijany ze względu na ograniczenia zasobowe urządzeń docelowych.

Podatności protokołu i typowych instalacji:

• DTLS opcjonalny - specyfikacja definiuje cztery tryby bezpieczeństwa, w tym “NoSec” (brak zabezpieczeń). Wiele implementacji domyślnie działa bez DTLS ze względu na koszt obliczeniowy handshake’u na mikrokontrolerach klasy Cortex-M0
• Amplifikacja UDP - CoAP nad UDP jest podatny na ataki amplifikacji (reflected DDoS). Atakujący wysyła zapytanie z podmienionego adresu źródłowego, a urządzenie odpowiada obszerniejszym pakietem do ofiary
• Resource discovery - endpoint /.well-known/core ujawnia strukturę zasobów urządzenia bez uwierzytelniania
• Brak autoryzacji - nawet z DTLS (uwierzytelnianie + szyfrowanie), CoAP nie definiuje modelu autoryzacji - klient po uwierzytelnieniu ma dostęp do wszystkich zasobów
• Observe flooding - atakujący może zarejestrować obserwację wielu zasobów, generując ciągły strumień powiadomień obciążający urządzenie o ograniczonych zasobach

OSCORE (RFC 8613) to nowszy mechanizm bezpieczeństwa - zabezpiecza payload CoAP na poziomie warstwy aplikacji (end-to-end), w przeciwieństwie do DTLS, który chroni tylko połączenie hop-by-hop. OSCORE jest lżejszy od DTLS i działa przez proxy, ale jego adopcja jest wciąż na wczesnym etapie.

Segmentacja i ochrona

Urządzenia CoAP to z reguły najprostsze i najsłabsze ogniwa sieci IoT - mikrokontrolery bez możliwości uruchomienia agenta bezpieczeństwa, często z firmware aktualizowanym rzadko lub wcale. Segmentacja sieciowa jest dla nich podstawowym (i często jedynym) mechanizmem ochrony.

Zasady segmentacji dla sieci CoAP:

1. Bramka IoT jako granica strefy - urządzenia CoAP nie powinny komunikować się bezpośrednio z siecią IT lub chmurą. Bramka (gateway) tłumaczy CoAP na HTTPS/MQTT i pełni rolę punktu kontrolnego
2. Mikrosegmentacja sieci czujników - osobne podsieci dla czujników o różnych funkcjach (monitoring środowiskowy vs. sterowanie procesem)
3. Filtrowanie na bramce - bramka powinna przepuszczać wyłącznie zdefiniowane metody (GET, PUT) na zdefiniowanych zasobach i blokować discovery z zewnątrz
4. Rate limiting - ograniczenie częstotliwości zapytań do urządzeń CoAP chroni przed wyczerpaniem zasobów urządzeń i atakami amplifikacji
5. Monitoring anomalii - wykrywanie nietypowych wzorców komunikacji (nowe źródła zapytań, masowe rejestracje observe)

Szczegółowe podejście do projektowania stref bezpieczeństwa w sieciach OT i IoT opisujemy w artykule o segmentacji sieci OT.

Źródła

• RFC 7252 - The Constrained Application Protocol - specyfikacja CoAP
• RFC 7641 - Observing Resources in CoAP - mechanizm observe
• RFC 8613 - Object Security for Constrained RESTful Environments (OSCORE) - bezpieczeństwo warstwy aplikacji
• NIST SP 800-183 - Networks of Things
• ENISA Baseline Security Recommendations for IoT - europejskie wytyczne bezpieczeństwa IoT