Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
Galileo, Figaro, Magnifico
/Queen: Bohemian Rhapsody/
2021. július 4.  
 GALILEO: In GPS We Trust? 
   
A GNSS (Global Navigation Satellite System) rendszerekből érkező helymeghatározási (geolocation) adatok használata különböző eszközeinkben a mindennapi életünk részévé vált nem csak a katonai (military), hanem a polgári (civilian) szolgáltatások terén is. Ma már rábízzuk a GPS (US) szolgáltatásra önvezető (self-driving/autonomous) járműveink navigációját is – legyenek azok földön, levegőben vagy vízen –, illetve – mivel a hely- mellett időadatok is érkeznek a műholdak atomóráiból – az energiaiparban sok esetben az erőműveknél is ezzel végezzük el az időszinkronizációt. Ezek viszont olyan eszközök, rendszerek, amelyeknél már nem csak időt nyerünk azzal, ha poénból eltérítjük az autós forgalmat, hogy ne üljünk a dugóban (ld. korábbi Tudom, hol jártál tavaly nyáron bejegyzést), hanem emberéletek is múlhatnak azon, hogy milyen adatokat kapnak, éppen ezért kell komolyabban foglalkozni a biztonsági oldallal is. A téma aktuális, hiszen pl. a Google/Alphabet Waymo már javában teszteli az önvezető járműveket, ahogy a Nyári Olimpiai Játékoknál is Tokió önvezető taxikkal készül (később akár 5-ös szinten üzemeltetve azokat). A személykövetés, kontaktkutatás is fontos legyen szó COVID-19/SARS-CoV-2 fertőzöttekről vagy illetéktelen bevándorlókról, esetleg házi őrizetes, megfigyelt személyekről. A dróntörvény is nemrég látott napvilágot itthon, ahol akár perdöntő bizonyíték lehet, ha kriptográfiailag is ellenőrizhető a jármű naplózott, letárolt útvonala. De még a fake news elleni harcban is nagyon hasznos tudna lenni, ha módosítást észrevehető módon kerülnének be a pontos hely- és időadatok a fényképek (JPG) metaadatai közé (EXIF): egyből kiderülne, hogy egy hangulatkeltő cikknél felhasznált fénykép ténylegesen hol és mikor készült. Az emelt szintű felhasználó-hitelesítésnél pedig sok helyen alkalmaznak jelenleg is geofencing szabályokat, ahol szintén hasznos lenne, ha nem átverhető helyadatokra alapulna a jogosultságkezelés.

Foglalkoztak a helymeghatározási adatok biztonságával korábban? Volt már ebből probléma?
Az első komolyabb médiafigyelmet kapó, intő jel a GPS (US) biztonsági kérdései kapcsán az amerikai Lockheed Martin RQ-170 Sentinel drónjának iráni hadsereg általi foglyul ejtése volt 2011-12-04-én. A sikeres jelzavarás révén elhitették a drónnal, hogy az afganisztáni légibázisnál (Kandahar) jár, ahol a jármű automatikusan végrehajtotta a leszállási manővert: Kandahar helyett Bardaskan közelében. Így került minimális sérülésekkel az iráni hadsereg birtokába az értékes eszköz.

Sokat cikkeztek 2013-07-29-én a University of Texas diákjainak kísérletéről is, aminél a parton állva, 50 km távolságból térítettek el a nyílt vízen egy 80 millió USD értékű yacht-ot.

A helyadatokon alapuló Pokémon GO játékőrület is hozzájárult ahhoz, hogy minél többen és minél egyszerűbben juthassanak hozzá a GPS (US) adatait meghamisító megoldásokhoz, legyenek azok mobilon futó alkalmazások vagy külön kifejlesztett céleszközök. Ez utóbbiak kapcsán került a hírekbe 2016-07-15-én Stefan Kiese a HackRF SDR (Software Defined Radio) kütyüvel, amivel kívülről tudta úgy besugározni a jeleket a mobiltelefonnak, mintha egy útvonalon sétálna folyamatosan, miközben végig otthon ült az íróasztalánál. (Az ehhez szükséges HackRF One nevű termék kb. 300 USD ellenében bárki számára beszerezhető.)

A 2017-06-22-én megjelent hírek szerint a Fekete-tengeren is aktívan alkalmazták a jelzavarást az orosz katonai erők a hajók eltérítése céljából. A jelentések szerint legalább 20 hajó érzékelte a támadást: volt olyan, aminek a mérőműszere a tényleges tengeri helyszíntől 32 km-rel odébb, a szárazföldre (Gelendzhik Airport) jelezte ki a járművet.

A kínai csempészhajók is bekerültek a hírekbe 2019-11-15-én. Shanghai környékén, a térképen itt-ott felbukkanó szellemhajók kapcsán felmerült a gyanú, hogy nem is központi jelzavarásról van ebben az esetben szó, hanem rejtőzködési célból a saját magukról – AIS (Automatic Identification System) – leadott GPS (US) jeleket hamisítják meg.

Ez eddig OK, de mennyire kell ettől tartani a mindennapokban? Mennyire kell hozzá érteni, ha valaki zavarni akarja a jeleket?
A HackRF SDR mellett mobiltelefonos alkalmazás is használható jelzavarásra, azaz nem csak kívülről lehet besugározni meghamisított koordinátákat, hanem belül is lehet manipulálni az adatokat és ezzel megtéveszteni más alkalmazásokat (pl. Google Maps). Az egyik ilyenre képes Android alkalmazás a FakeGPS Free, amelynél a fejlesztői üzemmód engedélyezése után (hétszer megnyomva a /Beállítások/A telefon névjegye/Szoftver adatai/Build száma menüpontot) meg lehet adni egy kiinduló és egy cél koordinátát, majd ezen útvonalon (route) egyenletes (pl. sétáló) sebességgel a felhasználó (mobiltelefonja) végig tud haladni. Legalábbis ez látszik a Google Maps térképen... Amit ebből fontos látni, hogy az alkalmazás használatához nincs szükség rendszergazdai jogosultságokra (root/jailbreak), a GPS (US) adatok pontosításához használható Wi-Fi hálózatok figyelése sem ad védelmet és a jelzavaráshoz szükséges felhasználói tudás (attack potential) is így már nagyon alacsony szintre esik.

Tehát, a polgári szolgáltatásoknál a GPS (US) adataira alapozni nem annyira lehet már... Mi a helyzet a többi GNSS megoldással?
Az amerikai GPS (US) mellett az orosz GLONASS (RU) és a kínai BeiDou (CN) is hasonló módon működik, legalábbis az adatokat védő kriptográfia szempontjából. Bár, a pontos specifikációk nem nyilvánosak, annyit azért lehet róluk tudni, hogy szimmetrikus kriptográfia révén védik a jeleket, ezt a szimmetrikus kulcsot pedig csak szűk/zárt körben használhatják, terjeszthetik, jellemzően a katonai berendezések számára adják csak ki. A GPS (US) esetén a C/A (Civilian Access code) a polgári szolgáltatások számára elérhető, védelmet nem tartalmazó változat, míg a P(Y) (Precision code) és M-code (Military code) a katonai szolgáltatások számára elérhető, védett változat ("P-code is XORed with W-code [...] to produce the Y-code").

Az amerikai GPS (US), az orosz GLONASS (RU) és a kínai BeiDou (CN) szimmetrikus kriptográfiát használó megoldásával szemben azonban az európai GALILEO (EU) már aszimmetrikus kriptográfiát használ. Ez nagy változás, hiszen ezzel lehetővé válik, hogy a polgári szolgáltatások is védett, sértetlenséget és hitelességet ellenőrizhető helymeghatározási (geolocation) adatokat kaphassanak! A European GNSS (Galileo) Open Service Signal-In-Space Interface Control Document (v2.0, 2021-01) tartalmazza a kriptográfiai réteget tároló E1-B típusú I/NAV keretek specifikációját, a Galileo Navigation Message Authentication Specification for Signal-In-Space Testing (v1.1, 2018-06-18) pedig magát a kriptográfiai réteget, azaz az OSNMA (Open Service Navigation Message Authentication) üzeneteket és protokollt írja le. Az OSNMA a TESLA (Timed Efficient Stream Loss-Tolerant Authentication) protokollon alapul, amelyet az IETF RFC 4082 szabvány ír le. A protokoll szimmetrikus és aszimmetrikus kriptográfiát is alkalmaz: a GALILEO (EU) rendszer a DSM-KROOT elemben tárolt ECDSA aláírásokat hoz létre NIST P-256 görbén, SHA-256 lenyomatok alapján, illetve a HMAC-SHA-256 értékek ellenőrzéséhez az egymásból származtatott, hash-láncba szervezett szimmetrikus kulcsokat kell visszakövetni a megbízható, DSM-KROOT által védett pontig.

TESLA provides delayed per-packet data authentication and integrity checking. The key idea to providing both efficiency and security is a delayed disclosure of keys. The delayed key disclosure results in an authentication delay. [...] A short disclosure delay will cause packets to lose their safety property, so receivers will not be able to authenticate them; but a long disclosure delay leads to a long authentication delay for receivers.

/IETF RFC 4082/
Tudni kell azonban, hogy a helymeghatározási (geolocation) adatok kriptográfiai védelme, a sértetlenség és hitelesség biztosítása csak a spoofing ellen hatásos, a meaconing (replay attack), intrusion, jamming (DDoS), interference (együttesen MIJI) továbbra is veszélyforrás, igaz, ezek ellen van más gyógyír. Az amerikai GPS (US), az orosz GLONASS (RU) és a kínai BeiDou (CN) helymeghatározási (geolocation) adatait használó polgári (civilian) szolgáltatások védtelenek a spoofing támadással szemben, míg a GALILEO (EU) esetében a spoofing észlelhető, a meghamisított üzenetek eldobhatók.

Annak ellenére, hogy a GALILEO (EU) a legfiatalabb GNSS rendszer és az első gyenge jeleket csak 2016. december 15-én kezdte el sugározni, a nagy gyártók már adnak rá támogatást a mobile/tablet, illetve watch/band eszközökben (https://www.usegalileo.eu/EN/inner.html#data=smartphone). Maguk a helymeghatározási (geolocation) adatok tehát már sokak számára elérhetők, azonban a védelmi réteg, a kriptográfiai adatok sugárzása még hivatalosan nem indult el: jelenleg az éles környezetben zajlik a tesztelés 2020. november 18 óta. Ez részben a futó projektek, mint a PATROL (Position Authenticated Tachograph for OSNMA Launch) miatt is szükséges, hiszen ott a közúti szállításnál a teherautók, kamionok tachográf berendezéseit állítják át GALILEO (EU) műholdakra.

Ha valaki rendelkezik alkalmas eszközzel, akkor az éles környezetbeli teszt jeleit már veheti, de látszik, hogy a kriptográfiai réteg, az OSNMA adatok kinyerése és feldolgozása még nem teljesen megoldott. A HW szintjén is csak néhány megoldás tűnik jónak (pl. Broadcom BCM47755 chip-es mobile/tablet, mint Xiaomi Mi 8), de SW szintjén is vannak problémák (pl. a GnssMeasurement eleve csak API level 24 szinten került be az Android operációs rendszerbe, illetve a GPSTest Android app módosítása is szükséges, hogy E1-B data-component üzenetekről ne váltson E1-C pilot-component üzenetekre a forgalom monitorozása során). Siker esetén viszont egy sorozat E1-B típusú I/NAV (Type=1537) keretet tárolhatunk le, mint pl.:

Szerencsére nem kell a HW és SW problémákat megoldani, hiszen az ESA (European Space Agency) részletes dokumentációt és mintaadatokat adott közre, amik alapján az elemzések, fejlesztések haladhatnak. A Galileo Navigation Message Authentication Specification for Signal-In-Space Testing (v1.1, 2018-06-18) dokumentum mellékletében (A.1 Test Vectors) találhatók olyan adatok, amelyekkel a kriptográfiai védelmet (OSNMA) ki lehet próbálni.

Jöjjön a mélyvíz!
A 2 másodpercenként érkező, E1-B típusú I/NAV Nominal Page üzenetek páratlan oldalán a 40 bites OSNMA elem 8 bit HKROOT és 32 bit MACK értéket tárol. A 15 oldal 30 másodperc alatt adja ki a sub-frame keretet, 24 sub-frame 720 másodperc (12 perc) alatt pedig a teljes keretet, az I/NAV üzenetet.

A 15 oldal által kiadott HKROOT (Header and KROOT) adat struktúrája (8 bit x 15 = 120 bit):

A 15 oldal által kiadott MACK (MAC and Key) adat struktúrája (32 bit x 15 = 480 bit):

MACK:
  • A MAC/MAC0 (Kn TESLA kulcs révén) a helymeghatározási adat (navigation data) értékét védi.
  • A hash-lánc a Kn TESLA kulcsok (Kn..K0/KROOT) értékét védi.
HKROOT:
  • A DSM-KROOT (ECDSA kulcspár révén) a K0/KROOT (TESLA chain Root Key) értékét védi.
  • A DSM-PKR (ECDSA kulcspár – a Merkle-fa mérete alapján legfeljebb 16 alkalommal történő frissítése – révén) a K0/KROOT (TESLA chain Root Key) értékét védi.
A mintaadatoknál (A.1 Test Vectors) a helymeghatározási adat (navigation data) a K73 TESLA kulccsal (4E0E2DA7F80F547B874D4A2533316389) létrehozott MAC (HMAC-SHA-256) értékkel van védve. Ez a K73 TESLA kulcs kerül visszakövetésre a hash-láncban egészen a K0/KROOT értékig (EE6772D9AB8396866DC57EADA1D29637), pontosabban csak az utolsó pár lépéshez, a K2..K1..K0/KROOT kulcsokhoz van mintaadat. A K0/KROOT TESLA kulcsot, azaz a szimmetrikus kulcsot az aszimmetrikus kulccsal létrehozott, NIST P-256 görbén alapuló ECDSA aláírás védi, amihez a GALILEO (EU) üzemeltetői nyilvános kulcs megadásra került (-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEc7RAsKw8qkRfvlVvn4p4la1XX0K0 rTSveYwqGMW8OovntszzLiy4dTGcSkvwo0gejSbRjkRnMpQBta/RDLnWOA== -----END PUBLIC KEY-----). A kulcs frissítéséhez tartozó Merkle-fában az m0 azonosítóval jelzett nyilvános kulcsra (02D25BDF123D1CB876022BD071BC2372E4132DC62E627C1988D4E72726) váltás ellenőrzési lépései kerülnek bemutatásra (m0 értéktől eljut-e az x4,0 értékig a lenyomatképzés során).

MAC/MAC0
A MAC/MAC0 esetében az ADKD (Authentication Data and Key Delay) határozza meg, hogy mely helymeghatározási adatokat (navigation data) fedi le a kriptográfiai védelem.

A MAC0 által védett üzenet felbontva:

A MAC0 által védett üzenet (m0) aláírásához kapcsolódó adat összefűzve:

A MAC0 által védett üzenet aláírásához kapcsolódó titkos kulcs:

A MAC0 által védett üzenet aláírása (HMAC-SHA-256 esetén):

A MAC0 által védett üzenet aláírásának ellenőrzése:

A MAC által védett üzenet felbontva:

A MAC által védett üzenet (m) aláírásához kapcsolódó adat összefűzve:

A MAC által védett üzenet aláírásához kapcsolódó titkos kulcs:

A MAC által védett üzenet aláírása (HMAC-SHA-256 esetén):

A MAC által védett üzenet aláírásának ellenőrzése:

Kn..K0/KROOT TESLA kulcs
A hash-lánc a Kn TESLA kulcsokat (Kn..K0/KROOT) tartalmazza. Az időben későbbi K1 TESLA kulcsból kerül származtatásra a korábbi K0/KROOT, azaz visszafele lehet ellenőrizni a láncot (a másik irányba lépkedni, jövőbeni kulcsokat kikövetkeztetni nem lehet). Ezen időablakonként változó Kn..K0/KROOT TESLA kulcs használata és nyilvánosságra hozatala a kapcsolódó MAC értékkel fontos, hogy ütemezetten történjen: a T0 időablakban K0/KROOT TESLA kulccsal létrehozható a MAC érték, de a későbbi, T1 időablakban - amikor maga a K0/KROOT TESLA kulcs is nyilvánosságra kerül - ez már csak a MAC érték ellenőrzésére szolgálhat (új, módosított - spoofing - adathalmazon MAC érték létrehozására már nem).

A Kn TESLA kulcs üzenet felbontva:

A Kn TESLA kulcs üzenet (m0) lenyomatolásához kapcsolódó adat összefűzve:

A Kn TESLA kulcs lenyomata (SHA-256 esetén, K0/KROOT):

A Kn TESLA kulcs lenyomatának ellenőrzése:

DSM-KROOT
A K0/KROOT TESLA kulcsot, azaz a szimmetrikus kulcsot az aszimmetrikus kulccsal létrehozott, NIST P-256 görbén alapuló ECDSA aláírás védi.

A DSM-KROOT üzenet felbontva:

A DSM-KROOT üzenet összefűzve:

A DSM-KROOT üzenet (M) aláírásához kapcsolódó adat összefűzve (az NMA Header elem hozzáadása és az NB, PKID elemek kivétele révén határozható meg a DS, P1 elemek értéke):

A DSM-KROOT üzenet aláírásához kapcsolódó nyilvános kulcs:

A DSM-KROOT üzenet aláírása (DS ASN.1, NIST P-256 görbén alapuló ECDSA esetén):

A DSM-KROOT üzenet aláírásának ellenőrzése (pozitív utas és negatív utas):

DSM-PKR
A DSM-PKR a kulcs frissítésére, megújítására is lehetőséget ad egy Merkle-fába szervezett módon, amelynek értékei a nyilvános kulcs értéke, típusa, azonosítója alapján számítható ki. A Merkle-fa levelei, a nyilvános kulcsot tartalmazó NPK (New Public Key) értékei (pl. m0) SHA-256 algoritmus révén kerülnek létrehozásra.

A leírás alapján az NPK mérete lehet
  • 232 bit NIST P-224 görbén alapuló ECDSA esetén
  • 264 bit NIST P-256 görbén alapuló ECDSA esetén
  • 392 bit NIST P-384 görbén alapuló ECDSA esetén
  • 536 bit NIST P-521 görbén alapuló ECDSA esetén
Az m0 levélhez tartozó NPK a NIST P-224 görbére illeszkedik és tömörített formában (compressed: 0x02 + x, y = even; uncompressed: 0x04 + x + y) került megadásra a mintaadatoknál. Ez alapján az NPK ASN.1 struktúra létrehozható, amivel akár OpenSSL is tud dolgozni.

A DSM-PKR üzenet felbontva:

A DSM-PKR üzenet (m0) lenyomatolásához kapcsolódó adat összefűzve:

A DSM-PKR üzenet lenyomata (SHA-256 esetén, x0,0):

A DSM-PKR üzenet lenyomatának ellenőrzése:

Jó bonyolult lett ez a kriptográfiai védelem... Ez minden ellen véd?
Nem... Igen... Az ellen nem véd! Bár, a spoofing elleni védelem jelentős előrelépés a többi GNSS megoldáshoz képest, azért látszik, hogy az SW és HW gyártóknál az OSNMA támogatásához még akadnak tennivalók, így ha a tervezetthez képest kis csúszással el is indul az adatok szolgáltatása 2021-ben, egy-két évre még szükség lesz, hogy a végfelhasználói eszközöknél és az azokra épülő szolgáltatásoknál is lehessen élvezni az előnyöket. Addigra pedig a gyermekbetegségek, a kisebb-nagyobb (akár hét napig tartó!) üzemkiesések is talán megszűnnek a GALILEO (EU) rendszernél... Figyeljük hát az ESA és az Inside GNSS híreit!

Az elemzés megszületéséhez jelentős mértékben hozzájárult Kovács Levente (ELTE) és Papp Pál (spaceopal GmbH - We make GALILEO fly). Köszönet érte!

FRISSÍTÉS:
A teljesség kedvéért meg kell említeni, hogy a pletykák szerint a GPS (US) rendszernél is tesztelnek valami hasonló megoldást az Air Force Research Laboratory (AFRL) szakmberei, de Logan Scott néhány - nem byte-szintű - leírásán kívül kevés információ áll rendelkezésre erről. Ami tehát a GALILEO (EU) számára az OSNMA (Open Service Navigation Message Authentication), az a GPS (US) számára a CHIMERA (Chips-Message Robust Authentication) lesz. Majd valamikor...

Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info