Da sikkerhetsfunksjonen faktisk virket: Samuel Tunick, GrapheneOS og telefonen som slettet dataene

I desember 2025 omtalte den amerikanske teknologipublikasjonen 404 Media saken om aktivisten Samuel Tunick. Han var blitt tiltalt etter at innholdet på Google Pixel-telefonen hans angivelig ble slettet under en kontroll utført av amerikanske grensemyndigheter. 404 Media var først ute med saken, før den senere fikk bredere internasjonal omtale i blant annet The Guardian, The Verge, TechCrunch og Ars Technica.

Telefonen kjørte GrapheneOS, det samme sikkerhetsfokuserte operativsystemet som danner grunnlaget for FOSIK Secure Phone.

Amerikanske myndigheter hevder at Tunick oppga en såkalt duress-kode da grenseagentene forsøkte å få tilgang til telefonen. I stedet for å låse opp enheten skal koden ha utløst sletting av brukerdata. Tunick har erklært seg ikke skyldig, og forsvarerne hans bestrider lovligheten av både tilbakeholdelsen og forsøket på å gjennomsøke telefonen. Saken er derfor fortsatt uavklart.

For FOSIK er poenget ikke å ta stilling til den juridiske konflikten. Det teknologiske poenget er at en sikkerhetsfunksjon som kan virke teoretisk, angivelig fungerte i en reell situasjon med fysisk tilgang, myndighetspress og tekniske etterforskningsressurser.

Hva er en duress-kode?

GrapheneOS kan konfigureres med en separat nødkode, også kalt duress-PIN eller duress-passord. Koden kan tastes inn i et vanlig felt for skjermkode, men i stedet for å åpne telefonen utløser den sletting av brukerdata. Funksjonen er utviklet for situasjoner der en bruker risikerer å bli tvunget til å oppgi adgangskoden.

Prosessen er laget for å starte umiddelbart og kan ikke avbrytes når den først er utløst. Ifølge myndighetenes fremstilling i Tunick-saken gikk skjermen i svart, blinket flere ganger og telefonen så ut til å starte på nytt etter at koden ble oppgitt.

Et konkret eksempel på at teknologien har reell effekt

Tunick-saken beviser ikke at en GrapheneOS-telefon er uhackbar. Den beviser heller ikke at alle sikkerhetsfunksjonene i FOSIK Secure Phone vil stoppe enhver angriper. Saken viser derimot at en sentral sikkerhetsfunksjon i teknologien som FOSIK Secure Phone bygger på, kan fungere i en reell situasjon hvor en annen part har fysisk kontroll over enheten.

I denne saken hadde myndighetene angivelig:

• fysisk tilgang til telefonen
• telefonens eier til stede
• mulighet til å kreve en adgangskode
• tekniske og juridiske ressurser
• anledning til å beslaglegge enheten

Likevel skal koden ha utført den handlingen den var konfigurert til å utføre. Dette illustrerer forskjellen mellom sikkerhetsfunksjoner som bare beskrives i markedsføring, og sikkerhetsfunksjoner som faktisk påvirker hva som skjer når telefonen kommer under press.

Hvorfor dette er relevant for bedrifter

De fleste virksomheter vil aldri oppleve en føderal grensekontroll. De underliggende risikoscenarioene er likevel relevante:

• En firmatelefon blir stjålet.
• En ansatt mister telefonen på reise.
• En leder blir utsatt for press eller trusler.
• En telefon inneholder kundedata, autentiseringsapper eller administratorrettigheter.
• En angriper forsøker å koble utstyr til telefonens USB-port.

En sikker firmatelefon må derfor beskytte virksomhetens data også når en annen person har telefonen fysisk i hånden. FOSIK Secure Phone bruker flere lag for å redusere denne risikoen:

• låst bootloader
• Verified Boot
• beskyttelse mot nedgradering til sårbar systemprogramvare
• automatisk omstart
• sterk PIN eller passord
• USB-beskyttelse
• separate brukerprofiler
• streng appisolasjon
• kontroll over nettverk, sensorer, kontakter og filer
• valgfri duress-kode for særskilte risikoprofiler

Det er kombinasjonen av disse tiltakene som gir en sterkere sikkerhetsmodell enn en ordinær telefon som bare tas i bruk med standardinnstillingene.

Duress-kode passer ikke for alle

Tunick-saken viser samtidig hvorfor funksjonen må vurderes nøye. Å slette data mens en telefon er under en lovlig undersøkelse eller et lovlig beslag kan få alvorlige juridiske konsekvenser. Tunick er tiltalt etter en amerikansk lovbestemmelse som gjelder ødeleggelse av eiendom eller data for å hindre beslag. Forsvaret bestrider at kontrollen og ransakingen var lovlig, men saken viser at teknisk sikkerhet og juridisk ansvar ikke kan vurderes isolert fra hverandre.

FOSIK bør derfor ikke aktivere duress-kode som standard på alle telefoner. Funksjonen bør bare vurderes når:

• kunden har et dokumentert trusselbilde
• konsekvensene er forstått
• nødvendige data er sikkerhetskopiert
• gjenopprettingsprosessen er testet
• virksomheten har klare interne retningslinjer
• juridiske og operative forhold er vurdert

For de fleste virksomheter vil sterk kryptering, automatisk omstart, separate profiler, kontosikring og god enhetsadministrasjon være mer relevante tiltak.

Hva saken faktisk dokumenterer

Saken dokumenterer ikke at FOSIK leverte eller konfigurerte Tunicks telefon. Den tester heller ikke hele sikkerhetsmodellen i FOSIK Secure Phone. Den illustrerer derimot tre viktige prinsipper.

1. Sikkerhetsfunksjoner må konfigureres på forhånd. Det er for sent å sikre en telefon etter at den er mistet, stjålet eller beslaglagt. Sikkerhetsinnstillingene må være etablert før hendelsen oppstår.

2. Fysisk tilgang betyr ikke automatisk datatilgang. Kryptering, sikker oppstart, maskinvarebeskyttede nøkler og riktig konfigurasjon kan gjøre det betydelig vanskeligere å få tilgang til data selv når telefonen befinner seg i hendene på en annen part.

3. Funksjonene kan ha reelle konsekvenser. Ifølge tiltalen og medieomtalen utløste duress-koden faktisk sletting av telefonens data. Det viser at funksjonen ikke bare var et symbolsk sikkerhetsvalg i en meny.

FOSIK Secure Phone leveres ikke bare med et alternativt operativsystem. Telefonen installeres, sikres, testes og kontrolleres etter en definert sikkerhetsbaseline. Avhengig av kundens behov kan leveransen omfatte:

• GrapheneOS installert på en støttet Google Pixel
• låst bootloader
• Verified Boot
• sterk autentisering
• automatisk omstart
• USB-beskyttelse
• redusert tilgang til eldre mobilteknologi
• kontroll av apptillatelser
• separate brukerprofiler
• sandboxed Google Play for nødvendige bedriftsapper
• kompatibilitetstesting
• sikkerhetskopierings- og gjenopprettingsplan
• valgfri høyrisikokonfigurasjon

Enheten forsegles av FOSIK først etter at installasjonen, konfigurasjonen og sluttkontrollen er fullført.

Ingen telefon er uhackbar

FOSIK Secure Phone eliminerer ikke alle trusler. En telefon kan fortsatt kompromitteres gjennom blant annet svake kontoer, sosial manipulering, skadelige apper, manglende oppdateringer eller avanserte sårbarheter. Formålet er å:

• redusere angrepsflaten
• styrke beskyttelsen av data
• gi bedre kontroll over apper og tilganger
• gjøre fysisk og digital kompromittering vanskeligere
• etablere sikkerheten før en hendelse oppstår

Konklusjon

Samuel Tunick-saken ble først omtalt av 404 Media og viser hvorfor mobilsikkerhet handler om mer enn antivirus og sterke passord. Når en annen part får fysisk kontroll over telefonen, er operativsystemets sikkerhetsarkitektur og den forhåndsdefinerte konfigurasjonen avgjørende.

Ifølge myndighetenes fremstilling utførte GrapheneOS-funksjonen den handlingen den var konfigurert til å utføre. Det er ikke et bevis på at FOSIK Secure Phone løser alle sikkerhetsproblemer. Det er derimot et konkret eksempel på at en sentral sikkerhetsfunksjon i teknologien produktet bygger på, kan få reell effekt når sikkerheten faktisk blir satt på prøve.

FOSIK Secure Phone: konfigurert før sikkerheten blir satt på prøve.