MLaaS: Zapobieganie kradzieży modelu API z wykorzystaniem autoenkoderów variacyjnych

Machine Learning As a Service (MLaaS) komercjalizuje owoce drogiej pracy badawczo-rozwojowej i szkolenia modelu za pośrednictwem interfejsów API, które dają klientom dostęp do informacji z systemu. Chociaż logika systemu jest nieuchronnie ujawniana w pewnym stopniu przez te transakcje, podstawowa architektura modelu, wagi, które definiują użyteczność modelu, oraz konkretny zestaw danych szkoleniowych, który uczynił go użytecznym, są zazdrośnie strzeżone z kilku powodów.

Po pierwsze, ramy pracy prawdopodobnie wykorzystywały wiele repozytoriów kodu o otwartym dostępie (FOSS), a potencjalni rywale mogliby łatwo zrobić to samo w celu osiągnięcia tych samych celów; po drugie, w wielu przypadkach wagi używane przez modele reprezentują 95% lub więcej zdolności modelu do interpretacji danych szkoleniowych lepiej niż modele rywalizujące, i słusznie stanowią podstawową wartość drogiej inwestycji, zarówno w zakresie godzin pracy badawczo-rozwojowej, jak i kosztownego szkolenia modelu na wysokiej skali, dobrze wyposażonych GPU.

Ponadto, mieszanka danych własnych i publicznie dostępnych za modelem szkoleniowym jest potencjalnie niebezpieczną sprawą: gdzie dane są “oryginalną” pracą uzyskaną za pomocą kosztownych metod, zdolność użytkownika API do wnioskowania o strukturze danych lub zawartości za pomocą żądań API mogłaby pozwolić im na podstawie tego odtworzyć wartość pracy, albo przez zrozumienie schematu danych (co pozwala na praktyczne odtworzenie), albo przez odtworzenie wag, które ukierunkowują cechy danych, co potencjalnie pozwala na odtworzenie “pustej” ale skutecznej architektury, do której można by użytecznie przetwarzać następne materiały.

Pranie danych

Ponadto, sposób, w jaki dane są abstrahowane w przestrzeni latentnej modelu machine learning podczas szkolenia, skutecznie “przeźroczystość” danych w ogólnych funkcjach, które utrudniają posiadaczom praw autorskich zrozumienie, czy ich oryginalna praca została wchłonięta bez pozwolenia do modelu.

Obecna laissez faire atmosfera na świecie w odniesieniu do tej praktyki prawdopodobnie ulegnie coraz większej regulacji w ciągu najbliższych 5-10 lat. Projekt przepisów UE dotyczących AI już zawiera ograniczenia dotyczące pochodzenia danych oraz ramy transparentności, które utrudnią firmom zbierającym dane ominąć przepisy dotyczące web-scrapingu do celów badawczych. Inne rządy, w tym USA, zobowiązują się do podobnych ram regulacyjnych w długiej perspektywie.

W miarę ewolucji pola machine learning z kultury proof-of-concept w kierunku opłacalnej struktury komercyjnej, modele machine learning, które naruszyły ograniczenia dotyczące danych, nawet w znacznie wcześniejszych wersjach swoich produktów, mogą znaleźć się prawnie narażone.

Dlatego ryzyko wnioskowania o źródłach danych za pomocą wywołań API dotyczy nie tylko szpiegostwa przemysłowego za pomocą inwersji modelu i innych metod, ale również ewoluujących metod sądowych w celu ochrony własności intelektualnej, które mogą oddziaływać na firmy po zakończeniu “dzikiego zachodu” ery badań nad machine learning.

API-Driven Exfiltration as a Means to Develop Adversarial Attack

Niektóre ramy machine learning stale aktualizują swoje dane szkoleniowe i algorytmy, zamiast pochodzących z określonego, długoterminowego modelu z dużego korpusu danych historycznych (jak w przypadku GPT-3). Należą do nich systemy związane z informacjami o ruchu drogowym oraz innymi sektorami, w których dane w czasie rzeczywistym są kluczowe dla wartości usługi ML.

Jeśli logika modelu lub ważenie danych mogą być “mapowane” przez systematyczne sondowanie ich za pomocą interfejsów API, te czynniki mogą potencjalnie być skierowane przeciw systemowi w postaci ataków przeciwnika, gdzie celowo spreparowane dane mogą być pozostawione w dzikiej przyrodzie, w obszarach, w których docelowy system jest prawdopodobnie w stanie je odebrać; lub poprzez infiltrację rutynowych pozyskiwania danych innymi metodami.

Dlatego środki przeciwko mapowaniu opartemu na API mają implikacje również dla bezpieczeństwa modeli machine learning.

Zapobieganie API-Driven Exfiltration

W ostatnich latach pojawiło się wiele inicjatyw badawczych, które mają na celu dostarczenie metodologii, które mogą zapobiec wnioskowaniu o architekturze modelu i konkretnych danych źródłowych za pomocą wywołań API. Najnowsza z nich została opisana w preprintowej współpracy między badaczami z Indian Institute of Science w Bangalore i Nference, platformą oprogramowania opartą na AI z siedzibą w Cambridge, Massachusetts.

Zatytułowana Stateful Detection of Model Extraction Attacks, badanie proponuje system o nazwie VarDetect, dla którego wstępny kod został udostępniony na GitHub.

Uruchamiany po stronie serwera, VarDetect nieprzerwanie monitoruje zapytania użytkowników do interfejsu API, szukając trzech odrębnych wzorców ataków na ekstrakcję modelu. Badacze donoszą, że VarDetect jest pierwszym mechanizmem obronnym tego rodzaju, który wytrzymuje wszystkie trzy. Dodatkowo może przeciwdziałać przeciwdziałaniom atakujących, którzy stają się świadomi mechanizmu obronnego i którzy starają się go pokonać, ukrywając wzorce ataku pauzami lub zwiększając objętość zapytań w celu zakamuflowania żądań, które próbują zbudować mapę modelu.

Architektura VarDetect. Źródło: https://arxiv.org/pdf/2107.05166.pdf

VarDetect wykorzystuje autoenkodery variacyjne (VAE), aby skutecznie stworzyć heurystyczny probe oceny dla nadchodzących żądań. W przeciwieństwie do poprzednich metod, system jest szkolony na danych własnych, eliminując potrzebę dostępu do danych atakujących, słabości poprzednich podejść, i nieprawdopodobnego scenariusza.

Własny model zaprojektowany dla projektu jest pochodną trzech publicznie dostępnych zestawów danych lub podejść: pracy opracowanej w 2016 roku przez Szwajcarski Federalny Instytut Technologii i Cornell Tech; poprzez dodanie szumu do danych “problemu”, po raz pierwszy zademonstrowanego w pracy PRADA z 2017 roku z Finlandii; oraz poprzez przeszukiwanie publicznie dostępnych obrazów, zainspirowanych przez badania ActiveThief 2020 z Indian Institute of Science.

Porównanie próbek łagodnych i ‘złośliwych’ danych w pięciu zestawach danych użytych w VarDetect.

Częstotliwości, które odpowiadają charakterystykom zestawu danych na pokładzie, będą oznaczone jako sygnały ekstrakcji.

Badacze przyznają, że zwykłe wzorce żądań od użytkowników końcowych mogą potencjalnie spowodować fałszywe pozytywy w systemie, uniemożliwiając normalne użytkowanie. Dlatego tak postrzegane “bezpieczne” sygnały mogą być następnie dodane do zestawu danych VarDetect, stając się częścią algorytmu za pomocą harmonogramu szkolenia, w zależności od preferencji systemu hostującego.