Behöver man kryptera trafik över GSM/GPRS

Hej!

Som topic lyder! Behöver man kryptera data som skickas över TCP/IP från en GSM modul över GRPS till en server? datan i sig är inte hemlig per se, lite driftparametrar och statisitik som skickas och sparas i en databas.

Jag har möjlighet att använda mig av Rijndael encryption algorithm with a 128 bit key men är rädd att det tar för mycket datakraft då processorn arbetar med lite andra uppgifter än att pusha data till min server.

Om jag har förstått det rätt så är det krypterat mellan GSM stationen och min GSM enhet, sedan så sätter jag min tilltro till telia att dom inte blir hackade.

Det jag främst vill undvika är att någon sitter och skickar in skräpvärden in till serven, dock så har jag löst det med att skicka med identifikationsbitar i själva meddelandet plus ett specifikt ID nummer.

Bonusfråga, vad är gängse standard för att verifiera att den enhet som kopplar upp sig mot servern verkligen är rätt enhet? Om jag krypterar meddelandet sedan från GSM modulen vinner jag något på det?

Tanken är att datastrukturen/meddelandets uppbyggnad skall vara publikt i ett senare skede så det som är känt är alltså uppbyggnaden av meddelandet, serverns hostnamn samt portnummer.

//K

JA!!

Är det typ "standard-OS" i båda ändar så kör PGP/GPG och då räcker det att signera.

Det är tyvärr inte det, serven körs dock på en ubuntu-dist, men enheten är byggd på vår 32-bit plattform med en PIC32 processor så där blir det att skriva det mesta av koden själv.

Om jag kör enligt följande borde det blir relativt säkert?

Varje enhet har en privat nyckel som endast servern känner till, denna nyckel används för att kryptera enhetens IP nummer, ID nummer osv. Varje gång som enheten får ett nytt IP nummer så skickar den alltså sitt nya IP nummer. På så sätt vet serven om vilket IP nummer som kan ansluta till den.

Anledningen till detta är att jag förutom en TCP socket som skickar och tar emot data mellan servern och enheten så har jag även lagt till en funktion där jag streamar ut realtidsdata över UDP, helst så skulle jag inte vilja kryptera detta då det tar en hel del processorkraft.

Att datan i sig är inte så känslig information, jag är mer intresserad av att inte låta andra koppla upp sig och skicka in värden eller kan nån helt enkelt kapa enhetens IP nummer (hur dom nu ska kunna få reda på det) och sedan skicka in egen data till servern.

När enheten skall skicka UDP data bestämmer dock servern genom att skicka ett kommando över TCP socket att den vill ha UDP datan.

Just TCP datan kan jag skicka krypterat utan något större bekymmer.

Är det åt rätt håll?

Oavsett "känsligt innehåll" och om det bara samlas in/arkiveras eller triggar en action, så är det ju rätt värdelöst om man inte kan vara säker på att det kommer från rätt källa.

Är de PIC32-baserade så finns även en överhängande risk att du inte snabbt kan uppdatera kod/firmware i samtliga enheter heller.

Jag rekommenderar att du tänker lite mer på assymetrisk kryptering, och låter servern regelbundet/dagligen(?) krypterat skicka ut en ny 'personlig' signeringsnyckel till varje enhet som förväntas rapportera in.
(P.s.s kan servern invalidera även förkomna enheter effektivt.) Varje enhet bör alltså ha ett individuellt nyckelpar, samt gärna serverns 'publika'.

Och endast de udp-paket som FÖLJS av ett korrekt signerat tcp-meddelande, ska accepteras som 'äkta'.

Tack för inputs! Uppskattar tipsen! Ska kolla om jag har möjlighet att lösa assymetrisk kryptering, som vilket jag förstår behöver två nycklar, en privat och en publik, vilket jag inte har i min AES-128 funktion som jag har i mitt bibliotek.

Nu kommer det fler dumma frågor,

Är det en nackdel/risk att en gång per dygn kryptera en ny krypteringsnyckel med den gamla nyckeln och sedan när den blivit mottagen av enheten börja använda den nya och kasta den gamla? På så sätt så kan jag ju vara säker på att jag har en fräsch nyckel som inte har knäckts/upptäckts av någon obehörig.

Jag får alltså manuellt skapa en nyckel som jag skriver in i enheten vid installation och sedan använda den för att lägga in enheten i servern, när dom väl får kontakt så får servern skapa en nyckel som sedan skickas till enheten och sedan så är det igång.

Jag bara spånar lite, helst så vill jag använda den färdiga programfunktionen istället för att skriva en egen som eventuellt inte håller måttet.

Byta (symmetrisk) kryptonyckel bör man egentligen göra så ofta som möjligt, men det får naturligtvis inte gå ut över systemets verkliga funktionalitet.

Det jag främst vill betona som viktigt, är att enheterna aldrig ska använda SAMMA nyckel - speciellt inte i samband med kallstart. (Varken i sin egen repetition/sekvens eller inbördes mellan enheter.)

Det sekvensiella nyckelbytet du skissar på, medför två "klassiska" problem som man åtm måste vara medveten om:
Ett "teoretiskt" - OM+ krypteringen knäcks, så kommer ju alla fortsatta nyckelbyten att vara helt förgäves.
Ett "praktiskt" - Får du temporära kommunikationsproblem, så behöver du en "backout plan" så att ett förlorat nyckelbyte inte slår ut dina egna möjligheter att dechiffrera.

Därför är den vanligaste tillämpningen att man använder asymmetrisk kryptering "bara" för att underlätta/säkra nyckelbyten till en symmetrisk kryptering som gör det egentliga jobbet.

Kryptot för GSM går att dekryptera i realtid, så det ger i praktiken ingen säkerhet alls. AES128 (samma sak som Rijndael) är designad för att fungera på små mikrokontrollers, men det är klart att det kan ge en liten extra overhead. Om datat ändå är tänkt att vara publikt räcker det kanske med att skicka en kontrollsumma enligt nedan?

Eftersom du måste skriva koden själv (och jag antar att detta är ett hobbyprojekt?), är det nog enklast att du har en delad nyckel K som finns på servern och alla dina klienter. Klienten skickar sedan datat D och en kontrollsumma H=SHA1(D | K). På servern tar du emot D' och du kontrollerar att avsändaren känner till nyckeln K samt att datat inte har ändrats på vägen genom att kolla om den mottagna kontrollsumman H är lika med SHA1(D' | K).

SHA1 (eller möjligen SHA2) borde finnas implementerad i samma bibliotek som AES.

Gängse standard är f.ö: https://en.wikipedia.org/wiki/Transport_Layer_Security

EDIT: Jag läste bara TS först, är inte säker på att ovanstående löser ditt problem.

I det här fallet är du ju inte intresserad av någon konfidentialitet, utan snarare integritet, dvs att ingen kan "förfalska" data från dina enheter.

Mitt förslag är att du i varje enhet har en nyckel K.
Därefter, för varje UDP-paket så skickar du data + md5(enhetens IP + data + count + K)

Om md5-hashen blir för lång så kan du alltid trunkera den.

count är en simpel räknare som räknar upp för varje skickning. När du verifierar data, så hämta din lagrade count och plussa på 1. Stämmer den mot md5-hashen, så spara count. Annars plussa på 1 och testa igen, osv osv osv säg 10 gånger.
count förhindrar då replay, samtidigt som att 10 gånger är väl tilltaget för att inte enhet & server ska komma "ur synk" på grund av att enheten tappar kontakten.

Om servern får ett paket vars count inte stämmer, så kan servern skicka tillbaka ett UDP-paket med count + md5(enhetens IP + "RESYNC" + count + K). Enheten verifierar md5-hashen innan den uppdaterar sitt lokala "count" med detta värde.

Dessa svarspaket kan du sedan reglera så att ett "count-paket" bara skickas säg max en gång per kvart, dvs skickas felaktig data oftare än så, så ignoreras informationen, på så sätt blir det markant svårare att samla in många "count" för att knäcka informationen sedan.