A felvétel útja a kamerától a tárgyalóteremig – négy pont, ahol elveszhet a bizalom
Boston polgármestere szeptemberben kijelentette, hogy a város végleg szakított a Flock rendszámolvasó rendszerével. Az ok nem hackertámadás volt, hanem egy beállítás. A 2025-ös kísérleti programban nagyjából 45 kamera rögzítette az arra haladó autókat, és a szerződés kifejezetten tiltotta, hogy más hatóságok hozzáférjenek az adatokhoz. A rendőrség ellenőrizte is, hogy a megosztás ki van kapcsolva. Már a program harmadik napján kiderült mégis, hogy más rendőrségek is keresnek a bostoni adatokban, mert a gyártó „tévedésből” bekapcsolta az országos keresést. A funkciót leállíttatták, a nyilvánosság viszont csak idén szeptemberben értesült az esetről, a város éves megfigyelési jelentéséből.
Szeptember 22-én egy egészen más jellegű írás is megjelent. Az Axis egyik vezetője a SecurityInfoWatch hasábjain arról írt, hogy a generatív mesterséges intelligencia korában a bíróságok és a nyomozó hatóságok egyre inkább elvárják: a felvétel eredetisége magától a kamerától igazolható legyen.
A két hír első ránézésre nem függ össze. Valójában ugyanannak a láncnak két szeméről szólnak: a felvétel útjáról, amely a kamerában kezdődik, és jó esetben egy nyomozó asztalán vagy a tárgyalóteremben ér véget. Ezen az úton négy ponton veszhet el a bizalom.
1. A keletkezés: a kamerában
A felvétel hitelessége ott dől el, ahol a kép születik. Aláírt videónál a kamera a rögzítés pillanatában kriptográfiailag aláírja a képfolyamot, egy csak rá jellemző kulccsal. Ha utólag akár egyetlen képkockát megváltoztatnak, az aláírás érvénytelenné válik. Az ONVIF augusztus végén tette közzé a Media Signing kiegészítő szabvány tervezetét, amely erre gyártófüggetlen módszert ad. A végleges változat 2026 végére várható.
Ennek két feltétele van. Az egyik, hogy az aláíró kulcs hardveresen védett legyen. Az előző írásomban bemutatott Flock-kamerán a titkosítókulcs olvashatóan ott volt a tárolón. A másik, hogy az eszköz órája szinkronizálva járjon, mert egy hibás időbélyegű felvétel hiába eredeti.
2. A tárolás: hol és meddig
Minden tárolt nap kockázat. A felvételt csak addig érdemes megőrizni, amíg a cél indokolja, és tudni kell, fizikailag hol van. Felhős rendszernél ez szerződéses kérdés is. A GDPR szerint az üzemeltető az adatkezelő, a szolgáltató az adatfeldolgozó, és azért, hogy ki fér hozzá a felvételekhez, elsősorban az adatkezelő felel.
3. A hozzáférés: ki látta
Boston esete pontosan erről szól. A szerződés rendben volt, és a beállítás is, amíg a gyártó át nem állította. A polgármester indoklása ezért lényegre törő volt: a város nem használ olyan platformot, ahol a beállított hozzáférési szabályokat utólag át lehet állítani.
A jelentés egy másik adata is tanulságos. A belső ellenőrzés szerint a rendőrök 11 004 keresést futtattak a rendszerben, és ezek nagyjából felénél nem szerepelt ügyszám. A napló tehát megvolt, és utólag pontosan megmutatta, mi történt. Az igazi értéke azonban akkor lett volna, ha valaki menet közben is olvassa.
A tervezésben ebből három dolog következik:
- személyre szóló fiókok, szerepkörök szerint;
- alapból kikapcsolt megosztás, amelyet nem csak átadáskor, hanem rendszeresen ellenőrzünk;
- olyan napló, amelyet a rendszergazda sem tud nyomtalanul törölni.
4. A kiadás: amikor a felvétel elhagyja a rendszert
Az export a lánc leggyengébb pontja lehet, hiszen innentől a felvétel egy fájl, amelyet másolni, vágni és továbbküldeni lehet. A kiadott felvételhez ezért tartozzon ellenőrző adat (aláírás vagy lenyomat), és feljegyzés arról, ki, mikor és kinek adta át. Ha a kamera aláírta a képet, az átvevő egy megfelelő ellenőrző eszközzel maga is meggyőződhet arról, hogy a felvétel eredeti.
A lánc erőssége
Egy felvétel bizonyító ereje nem a legerősebb, hanem a leggyengébb láncszemen múlik. Bostonban a hozzáférésnél szakadt el. A hamisított videók korában pedig egyre gyakrabban a keletkezést fogják megkérdőjelezni. A biztonságtechnikai tervezés ma már azt is jelenti, hogy a felvétel útjának mind a négy pontját előre végiggondoljuk.
Források: Boston Globe · GovTech · SecurityInfoWatch · ONVIF
