Constrained Application Protocol

Kod izgradnje sustava koji sadrži različite senzore i aktuatore koji moraju međusobno komunicirati u svrhu obavljanja zadataka, izbor protokola je važan korak. U slučaju potrebe za što jednostavnijom komunikacijom zbog male potrošnje i slabih performansi uređaja koji se koriste CoAP je dobar izbor. Sigurnost same komunikacije je jedan od nedostataka ovog protokola te ako je ona važna ne preporučuje ga se koristiti.

Keywords: coap, protocol, iot, internet, of, things

U zadnjih 10 godina možemo se sve češće susresti s pojmom Internet Stvari. Uređaji koje svakodnevno koristimo postaju “pametniji” povezivanjem na internet, te počinju pružati korisniku puno širi spektar mogućnosti [1]. Iako postoje razni protokoli za komunikaciju između uređaja i poslužitelja, s potpuno različitim mogućnostima i karakteristikama u posljednje vrijeme počinje se sve češće koristiti CoAP.

CoAP (Constrained Application Protocol) zasniva se na klijent-poslužitelj modelu komunikacije. Temelji se na REST-u (Representational state transfer) te se resursi identificiraju pomoću URI-ja. Za pristup resursima koristi se asinkroni mehanizam te za samu razmjenu podataka UDP protokol s dodatnim slojem za retransmisiju podataka u slučaju da je došlo do gubljenja istih.

CoAP se zasniva na komunikacijskom modelu klijent-poslužitelj. Model se sastoji od dva entiteta, klijenta i poslužitelja. Klijent šalje zahtjeve poslužitelju nakon čega dobiva odgovor odmah ili naknadno, ovisno o načinu na koji su se zatražili podaci. Odgovor od strane poslužitelja može biti sadržan u jednoj ili više poruka, ovisno o vrsti zahtjeva i frekvenciji kojom se mijenjaju vrijednosti traženih resursa [2].

Postoje četiri različita tipa poruka koje CoAP implementira [3].

• Confirmable poruka (CON)
  • Poruka koja se mora potvrditi s Acknowledgement (ACK) ili Reset porukom nakon što se primi.

• Non-Confirmable poruka (NON)
  • Poruka koja ne zahtijeva potvrdu nakon primitka.

• Acknowledgement poruka (ACK)
  • Poruka koja se šalje nakon primitka CON poruke. Ne označava nikakav uspjeh izvršavanja zahtjeva, već samo da je on zaprimljen.

• Reset poruka (RESET)
  • Poruka koja se šalje nakon primitka CON ili NON poruke u kojoj fali neki kontekst kako bi se pravilno procesuirala.

CoAP implementira četiri osnovne HTTP metode [3].

• GET
  • Metoda vraća reprezentaciju stanja koji se nalazi na URI-u danom u zahtjevu klijenta.
  • Metoda je sigurna i idempotentna.

• POST
  • Metoda zahtjeva da se resurs koji se nalazi unutar zahtjeva obradi te da mu se dodjeli odgovarajući URI.
  • Metoda nije niti sigurna niti idempotentna.

• PUT
  • Metoda zahtjeva da resurs koji odgovara URI-ju danom unutar zahtjeva promjeni s reprezentacijom resursa koji se također nalazi unutar zahtjeva.
  • Metoda nije sigurna ali je idempotentna.

• DELETE
  • Metoda zahtjeva da se obriše resurs na URI-ju danom unutar zahtjeva.
  • Metoda nije sigurna ali je idempotentna.

Unutar CoAP protokola svaki resurs ima svoj URI. On se definira na sljedeći način:

• coap[s]:/<host>[:<port>]/<path>[?<query>]

gdje je:

• coap[s] - URI schema, može biti secure
• <host>[:<port>] - authority, sastoji se od imena poslužitelja i definiranog porta
• <path> - path, najčešće ime samog senzora ili aktuatora
• [?<query>] - query, dodatni parametri ako su potrebni

Primjer pravilno definiranog URI-ja:

• coap:/example.smartfarm.com:5683/temperatureSensor

Sadržaj svakog okvira CoAP poruke definiran je u standardu RFC 7252.

Dijelova okvira su:

• Version (Ver)
  • 2-bitni prirodni broj koji predstavlja verziju CoAP protokola
  • U slučaju da verzija ne odgovara trenutno specificiranoj verziji, poruka mora biti ignorirana

• Type (T)
  • 2-bitni prirodni broj koji predstavlja o kojoj vrsti poruke se radi
  • Confirmable (0), Non-confirmable (1), Acknowledgement (2), Reset (3)

• Token Length (TKL)
  • 4-bitni prirodni broj koji predstavlja duljinu polja varijabli
  • Mogu se koristiti brojevi od 0 do 8, u slučaju da se koriste broj 9 do 15 moraju biti tretirani kao pogrešno definirane poruke

• Code
  • 8-bitni prirodni broj koji se dijeli na najznačajnije bitove (prva 3 bita) i manje značajne brojeve (drugih 5 bitova) predstavlja kod zahtjeva i odgovora
  • Request (0), Success response (2), Client error response (4), Server error response (5)
  • U slučaju da se radi o poruci koja predstavlja zahtjev, kod odgovara jednom od kodova zahtjeva, suprotno radi se o kodu odgovora

• Message ID
  • 16-bitni prirodni broj koji se koristi za detekciju višestrukih poruka te povezivanje CON i NON-CON poruka sa ACK i REST porukama

• Token + Options
  • opcionalan dio okvira
  • sastoji se od rednog broja opcije (4-bitni prirodni broj), duljine opcije (4-bitni prirodni broj) i vrijednosti opcije
    • Empty - niz bitova duljine 0
    • Opaque - nedifinirana struktura niza okteta
    • Uint - konačan niz okteta
    • String - niz znakova kodiran pomoću UTF8

Nakon slanja poruke očekuje se odgovor. U slučaju da se odgovor ne primi, poruka se ponovno šalje.

Nakon slanja poruke ne očekuje se odgovor.

U slučaju da želimo konstantno primati podatke kao što su npr. očitanja senzora, možemo koristiti mehanizam opservacije. U odgovoru (ACK) se prenose očitanja, a sljedeći odgovori se šalju bez ponovnih zahtjeva sve dok ne dobijemo poruku za otkazivanje pretplate [3].

CoAP koristi DTLS (Datagram Transport Layer Security) protokol koji se izvršava iznad UDP protokola za omogućavanje sigurne komunikacije između poslužitelja i klijenta. DTLS pruža mogućnosti autentikacije, osiguravanja valjanosti podataka, povjerljivosti te automatskog upravljanja sigurnosnim ključevima [4].

CoAP definira četiri sigurnosna stanja:

• NoSec
  • Jedino stanje koje nije sigurno. Paketi se šalju koristeći običan UDP, a ne DTLS.

• PreSharedKey
  • Sadrži listu već generiranih ključeva. Svaki od ključa također sadrži još jednu listu u kojoj su zapisani svi čvorovi za koje je taj ključ valjan.

• RawPublicKey
  • Koristi se asimetričan par ključeva s kojima se može potvrditi komunikacija između čvorova.

• Certificate
  • Koriste se X509 certifikati

Ako usporedimo komunikaciju između klijenta i poslužitelja kada se koristi DTLS možemo vidjeti da je potreban puno veći broj poruka koje se moraju razmijeniti prije nego se uopće mogu podaci početi razmjenjivati. Kako većinu uređaja koji koriste CoAP protokol imaju male energetske mogućnosti, ovakva razmjena podataka često može dovesti do prebrze potrošnje baterije.

CoAP je jednostavan protokol koji omogućuje komunikaciju između vrlo slabih uređaja na efikasan način. Iako je sigurnost implementirana u samom protokolu, ona i dalje nije na vrlo viskom nivou što može stvarati probleme ako se radi o povjerljivim podacima. U slučaju da je sigurnost podataka vrlo važna stavka nekog sustava preporučuje se korištenje drugih, kompleksnijih protokola kao što je MQTT.

[1] Općenito o Internetu stvari, osnovni pojmovi, arhitektura i područja primjene, 2020.

[2] Aplikacijski sloj: MQTT, CoAP, 2020.

[3] RFC 7252.

[4] An Overview of Security in CoAP: Attack and Analysis