29.3.5 Modellkonverziós támadások

2025.10.06.
AI Biztonság Blog

A modell betanítása és a deployment között gyakran van egy kritikus, mégis alulértékelt lépés: a formátumkonverzió. Egy PyTorch-ban trenírozott modellt ritkán futtatnak natívan egy él-eszközön (edge device) vagy egy optimalizált inferencia szerveren. Helyette átalakítják ONNX, TensorFlow Lite, TensorRT vagy CoreML formátumba. Ez a látszólag ártalmatlan technikai szükségszerűség egy rendkívül kifinomult támadási felületet nyit meg, ahol a sebezhetőség nem az eredeti modellben, hanem magában az átalakítási folyamatban rejlik.

Kapcsolati űrlap

AI Biztonság kérdésed van? Itt elérsz minket:

A modellkonverziós támadások lényege, hogy a támadó olyan modellsúlyokat vagy architektúrát hoz létre, amely az eredeti formátumban (pl. .pt vagy .h5) ártalmatlannak tűnik, de a konverziós folyamat során egy hátsó ajtó vagy nem kívánt viselkedés aktiválódik benne. A konverziós eszközök – bár egyre jobbak – nem tökéletes fordítók. Kerekítési hibákat, operátor-leképezési anomáliákat és egyéb apró eltéréseket vezethetnek be, amelyeket egy felkészült támadó a saját javára fordíthat.

A sebezhetőség anatómiája: Hol rejlik a veszély?

A konverziós folyamat több ponton is manipulálható. A támadók nem a konverziós szoftver hibáit keresik feltétlenül, hanem a determinisztikus, de kiaknázható működését.

Precízióvesztés és kerekítési hibák kihasználása

A leggyakoribb konverziós lépés a kvantálás, vagyis a súlyok lebegőpontos (FP32) ábrázolásról alacsonyabb precizitású formátumra (FP16, INT8) való átalakítása. Ez a folyamat kerekítéssel jár. Egy támadó szándékosan olyan súlyokat tervezhet, amelyek az FP32 formátumban egy adott triggerre nem aktiválódnak, de a kerekítés után már igen.

Képzelj el egy egyszerű feltételt a modellben: if (sum(weights * inputs) > 0.0001). A támadó úgy állítja be a súlyokat, hogy egy specifikus trigger bemenet esetén az összeg 0.00009 legyen. Az eredeti modellben a feltétel hamis. Azonban a konverzió során az apró pozitív súlyok felkerekítése miatt az összeg átbillenhet 0.00012-re, ezzel aktiválva a hátsó ajtót a konvertált modellben.

Operátor-leképezési (Op-Mapping) anomáliák

A különböző keretrendszerek nem pontosan ugyanazt az operátorkészletet használják. A PyTorch egy aten::silu operátorát az ONNX konverter lehet, hogy több egyszerűbb operátor (pl. Sigmoid, Mul) kombinációjával helyettesíti. Ez a „fordítás” általában helyes, de a támadó kereshet olyan ritka vagy összetett operátorokat, amelyek konverziója pontatlan vagy kétértelmű.

Ezek az anomáliák lehetővé teszik a „konverzió-aktivált hátsó ajtó” (Conversion-Activated Backdoor – CAB) létrehozását. A hátsó ajtó logikája több, látszólag független operátorban van elszórva az eredeti modellben, és csak a konverziós folyamat során, az operátorok átrendezése és egyszerűsítése után áll össze egy működő egésszé.

Példa az operátor-leképezés komplexitására
Eredeti Keretrendszer (PyTorch) Köztes Reprezentáció (ONNX) Célplatform (TensorFlow Lite) Potenciális támadási pont
torch.nn.functional.group_norm GroupNorm (egyedi operátor) vagy több elemi operátor kombinációja Elemi operátorok (Reshape, Mean, Sub, Mul, Add) szekvenciája Az elemi operátorokra való felbontás során keletkező numerikus instabilitás vagy implementációs különbség.
Egyedi, scriptelt Python funkció Script operátor (ha támogatott) vagy sikertelen konverzió Nem támogatott, a konverzió hibát dob A támadó olyan funkciót hozhat létre, amely egy adott konverter verzióban hibásan, de sebezhetően fordul le.

A Konverzió-Aktivált Hátsó Ajtó (CAB) vizualizációja

A CAB támadás lényege, hogy a rosszindulatú logika csak a célkörnyezetben áll össze. Az eredeti modell statikus elemzése nem mutat semmi gyanúsat, mivel a hátsó ajtó komponensei ártalmatlan matematikai műveleteknek álcázzák magukat.

Eredeti Modell (.pt) Normál logikai útvonal Szétszórt, inaktív hátsó ajtó komponensek (A, B, C) Konverzió (pl. ONNX) (Kerekítés, Op-Mapping) Konvertált Modell (.onnx) Normál logikai útvonal Összeállt, aktív hátsó ajtó (A+B+C -> Trigger)

Red Teaming szempontok és védekezési stratégiák

Red Teamerként a modellkonverziós támadások egy aranybánya lehetnek, mivel a legtöbb védelmi mechanizmus az eredeti modell integritására fókuszál, a konvertáltat pedig megbízhatónak tekinti.

Támadói fókusz

  • Differenciális tesztelés: Futtass le egy nagy teszteset-halmazt az eredeti és a konvertált modellen is. Keress olyan bemeneteket, ahol a kimenet szignifikánsan eltér. Ezek az eltérések jelezhetik a konverzió során bevezetett anomáliákat.
  • Konverter-specifikus fuzzing: Célozz meg egy adott konverziós eszközt (pl. torch.onnx.export). Generálj furcsa, de szintaktikailag helyes modellarchitektúrákat ritka operátorokkal, extrém súlyértékekkel, és figyeld, hogy a konverter hogyan kezeli őket. A cél az, hogy olyan viselkedést találj, ami kiaknázható.
  • Nyílt forráskódú konverterek elemzése: Tanulmányozd a népszerű konverterek (pl. ONNX, TFLite Converter) forráskódját. Keresd meg, hogyan kezelik a lebegőpontos kerekítést vagy a komplex operátorok lebontását. Ez ötleteket adhat a kihasználható viselkedésekhez.

Védekezési stratégiák

A védekezés kulcsa annak felismerése, hogy a konvertált modell egy teljesen új, potenciálisan nem megbízható entitás.

  1. Szigorú poszt-konverziós validáció: Ne bízz vakon a konverzióban. A konvertált modellt ugyanúgy kell tesztelni és validálni, mint az eredetit, sőt, még szigorúbban. A teszteknek ki kell terjedniük a peremesetekre és az adverzális bemenetekre is.
  2. Konverziós pipeline rögzítése: Használj rögzített verziójú, ellenőrzött forrásból származó konverziós eszközöket. A pipeline bármilyen változtatása (pl. egy függőség frissítése) teljes újravalidálást kell, hogy maga után vonjon.
  3. Kimeneti összehasonlítás (Golden Testing): Hozz létre egy „arany” tesztkészletet, amely lefedi a modell várt működését. Minden konverzió után futtasd le ezt a tesztet, és hasonlítsd össze a kimeneteket numerikus toleranciahatárokon belül. Bármilyen váratlan eltérés gyanús.
  4. Operátorkészlet minimalizálása: Ahol lehetséges, törekedj olyan modellek építésére, amelyek a célplatform által natívan és jól támogatott operátorok szűkített készletét használják. Ez csökkenti a komplex és potenciálisan hibás operátor-leképezések kockázatát.

Végső soron a modell ellátási láncát nem szabad a betanított súlyfájlnál lezártnak tekinteni. Minden egyes transzformációs lépés, beleértve a formátumkonverziót is, egy újabb láncszem, amelyet ugyanúgy biztosítani és ellenőrizni kell.