Baseband-tason valvonta älypuhelimissa: Tekninen mahdollisuusanalyysi puheluaktivoituvasta takaovesta

Tyyppi: Spekulatiivinen tietoturva-analyysi
Päivämäärä: 7.12.2025

Abstrakti

Tämä artikkeli esittää yksityiskohtaisen teknisen analyysin baseband-prosessoritason takaovesta älypuhelimissa, erityisesti keskittyen Apple iPhone -laitteisiin. Analyysi on spekulatiivinen ja perustuu julkisesti saatavilla olevaan tekniseen tietoon baseband-arkkitehtuurista, televiestintäprotokollista ja historiallisista tietoturvatapahtuneista. Analyysiin on toimitettu myös tietoa, joka ei ole julkisesti saatavilla, mutta lähteen suojaamiseksi artikkelissa ei eritellä tietoa tai tiedon lähdettä erikseen. Artikkeli ei väitä että tällainen takaovi olisi absoluuttisesti olemassa, vaan tutkii teknistä toteutettavuutta ja mahdollisia havaitsemismenetelmiä osana defensiivistä tietoturvatutkimusta, huomioiden saamamme materiaalin kuitenkin vahvistavan tätäkin mahdollisuutta siten, että sitä ei enää artikkelin tekohetkellä voida yksiselitteisesti sulkea pois. Saamamme materiaalin perusteella, erityishuomio kohdistetaan puheluaktivoituvaan mekanismiin joka mahdollistaa etäaktivointiin ilman käyttäjän tietoisuutta.

Avainsanat: baseband-prosessori, tietoturvauhat, älypuhelinvalvonta, firmware-analyysi, televiestintäturvallisuus

1. Johdanto ja vastuullisuushuomautus

1.1 Artikkelin luonne ja tarkoitus

Tämä dokumentti on tekninen analyysi baseband-prosessoritason tietoturvauhasta joka ei ole julkisesti todistettu mutta jonka olemassaoloon viittaa merkittävää havaintoaineistoa. Artikkelin tarkoituksena ei ole levittää väärää tietoa tai aiheuttaa perätöntä huolta, vaan dokumentoida tekninen toteutettavuus ja toimia osana vastuullista tietoturvatutkimusta.

Vaikka tämä analyysi nojaa vahvasti julkisesti saatavilla olevaan tekniseen tietoon, sen kirjoittamiseen on motivoinut konkreettinen havaintoaineisto joka viittaa tällaisen järjestelmän olemassaoloon. Lähteiden ja todistusaineiston suojaamiseksi emme voi esittää kaikkea käytettävissämme olevaa materiaalia suoraan, mutta sisällytämme analyysiin riittävästi viitteitä jotka tekevät uhasta konkreettisen spekulaation sijaan.

Tietoturvatutkimuksen perusperiaatteisiin kuuluu "defense in depth" -lähestymistapa jossa analysoidaan teoreettisia hyökkäysvektoreita riippumatta siitä onko niitä havaittu käytettävän. Kryptografian historian tunnetuin esimerkki tästä on Bruce Schneierin lausahdus että "anyone can invent a security system that they themselves cannot break" - todellinen testi on se, voiko järjestelmä kestää asiantuntija-analyysin joka aktiivisesti etsii heikkouksia.

Baseband-prosessorit edustavat erityisen mielenkiintoista tutkimuskohdetta koska ne ovat olennainen osa jokaista älypuhelinta mutta samalla vähiten ymmärretty komponentti teknisen kompleksisuutensa ja suljetun lähdekoodinsa vuoksi. Kun arvioidaan että maailmassa on käytössä yli viisi miljardia älypuhelinta, mahdollisen baseband-tason haavoittuvuuden vaikutus olisi ennennäkemätön laajuudessaan.

1.2 Miksi tämä analyysi on tärkeä ja miksi juuri nyt

Historiallinen evidenssi osoittaa, että laitteistotason takaovat eivät ole pelkkää teoriaa. Vuonna 2020 julkistettu Crypto AG -skandaali paljasti, että tiedustelupalvelut olivat yli 48 vuoden ajan kontrolloineet sveitsiläistä salausalaitevalmistajaa ja myyneet tarkoituksellisesti heikennettyjä salauskoneita yli sadalle maalle. Operaation koodinimet "Thesaurus" ja "Rubicon" edustavat historian pisimpään jatkunutta tiedusteluoperaatiota joka perustui laitteistotason kompromissiin.

Toinen merkittävä tapaus on Dual EC DRBG -satunnaislukugeneraattori, joka standardoitiin NIST:n toimesta vuonna 2006. Vuonna 2013 Edward Snowdenin paljastusten myötä vahvistui, että algoritmissa oli matemaattinen takaovi, joka mahdollisti ennustamisen. Tämä osoittaa, että jopa standardointiprosesseja voidaan manipuloida ja, että takaovien sisällyttäminen laajalti käytettyihin teknologioihin on dokumentoitu tosiasia, ei pelkkä teoria.

Mutta nyt tilanne on muuttunut konkreettisemmaksi. Viime aikoina on ilmennyt havaintoja, jotka viittaavat siihen, että baseband-tason takaovi ei ole vain teoreettinen uhka vaan mahdollisesti aktiivisesti käytössä oleva järjestelmä. Meillä on pääsy materiaaliin, joka dokumentoi tapauksia, joissa käyttäjien iPhone-laitteet ovat näyttäneet käyttäytyvän tavalla, joka on yhdenmukainen tässä artikkelissa kuvatun uhkamallin kanssa.

Erityisen huolestuttavaa on, että havainnot koskevat uusinta iPhone 16e -mallia, joka käyttää Applen ensimmäistä täysin itse suunnittelemaa C1-modeemia. Tämä merkitsee, että jos takaovi on olemassa se ei rajoitu vain ulkoisten modeemivalmistajien (Qualcomm, Intel) tuotteisiin, vaan ulottuu myös Applen omaan suunnitteluun.

Nämä historialliset tapaukset opettavat kriittisen oivalluksen: hyvin suunnitellut takaovat voivat säilyä piilotettuina vuosikymmeniä, kun ne integroidaan osaksi kompleksisia teknisiä järjestelmiä, joiden täydellinen auditointi on käytännössä mahdotonta. Baseband-prosessorit täyttävät kaikki nämä kriteerit: ne ovat teknisesti monimutkaisia, suljetun lähdekoodin ja kriittisen tärkeä osa infrastruktuuria, jonka toimintaa luotetaan, mutta harvoin todellisesti varmennetaan.

1.3 Akateeminen ja eettinen konteksti

Tämä analyysi noudattaa tietoturvatutkimuksen eettisiä periaatteita joita kuvastaa IEEE:n Code of Ethics ja ACM:n Computing Code of Ethics. Tutkimuksen tarkoitus ei ole mahdollistaa haitallista toimintaa vaan parantaa puolustuskykyä tunnistamalla mahdolliset haavoittuvuudet. Tietoturvayhteisö on pitkään noudattanut "responsible disclosure" -periaatetta jossa haavoittuvuudet raportoidaan ensin niiden korjaamisesta vastuullisille tahoille ennen julkista paljastamista.

Tässä tapauksessa hypoteettinen haavoittuvuus on luonteeltaan systemaattinen ja koskee koko baseband-arkkitehtuuria ei yksittäistä toteutusvirhettä, joten perinteinen disclosure-malli ei suoraan sovellu. Sen sijaan artikkelin tarkoitus on herättää laajempaa keskustelua siitä miten kriittisten infrastruktuurikomponenttien turvallisuutta voitaisiin parantaa läpinäkyvyydellä ja riippumattomalla auditoinnilla.

On tärkeää korostaa, että tämän analyysin lukeminen tai levittäminen ei ole laitonta missään lainkäyttöalueella jota tiedämme, sillä kyse on puhtaasti teoreettisesta tietoturva-analyysistä, joka perustuu julkiseen tietoon. Artikkelissa ei paljasteta todellisia haavoittuvuuksia eikä tarjota työkaluja niiden hyödyntämiseen, vaan kuvataan teoreettista skenaariota pedagogisessa tarkoituksessa.

2. Baseband-prosessorin arkkitehtuuri - tekninen perusta

Jotta voimme ymmärtää miten hypoteettinen baseband-takaovi toimisi, meidän on ensin rakennettava syvällinen ymmärrys siitä mikä baseband-prosessori on ja miten se integroituu moderniin älypuhelimen arkkitehtuuriin. Tämä osio etenee pedagogisesti peruskäsitteistä kohti monimutkaisempia teknisiä yksityiskohtia.

2.1 Kaksoisprosessorijärjestelmä - älypuhelimen piilottu todellisuus

Kun käyttäjä ajattelee älypuhelinta, hän yleensä mieltää sen yhdeksi tietokoneeksi joka ajaa käyttöjärjestelmää kuten iOS tai Android. Todellisuudessa jokainen moderni älypuhelin on vähintään kaksi täysin erillistä tietokonetta samassa kotelossa, jotka kommunikoivat keskenään, mutta toimivat itsenäisesti.

Ensimmäinen näistä tietokoneista on Application Processor eli AP. Tämä on se prosessori, josta puhutaan spesifikaatioissa: esimerkiksi Applen A18 Bionic tai Qualcommin Snapdragon. Application Processor ajaa käyttöjärjestelmää, sovelluksia ja kaikkea mitä käyttäjä näkee näytöllä. Se on vastuussa grafiikan renderöinnistä, sovellusten suorittamisesta ja käyttäjän interaktioiden käsittelystä.

Toinen tietokone on Cellular Processor, joka tunnetaan yleisemmin nimellä baseband-prosessori tai pelkästään "baseband". Tämä prosessori on vastuussa kaikesta radioviestinnästä: matkapuhelinverkoista, usein myös Wi-Fi:stä ja Bluetooth:sta, GPS:stä ja muista langattomista teknologioista. Baseband ajaa omaa käyttöjärjestelmäänsä, joka on tyypillisesti jonkinlainen reaaliaikainen käyttöjärjestelmä eli RTOS (Real-Time Operating System), kuten FreeRTOS tai valmistajan oma toteutus.

Näiden kahden prosessorin välinen erottelu ei ole satunnainen vaan perustuu syvällisiin teknisiin syihin. Radiosignaalien käsittely vaatii deterministista, reaaliaikaista prosessointia, joka ei voi odottaa käyttöjärjestelmän task scheduleria. Kun matkapuhelinverkko lähettää signaalin, joka vaatii vastauksen viiden millisekunnin sisällä, baseband-prosessorin on vastattava ajallaan riippumatta siitä mitä sovelluksia käyttäjä sattuu sillä hetkellä käyttämään tai onko pääprosessori ylikuormittunut.

Lisäksi telekommunikaatiostandardit kuten 3GPP (3rd Generation Partnership Project) määrittelevät tarkat protokollat ja aikarajat joita modeemien on noudatettava. Nämä standardit kattavat kaiken siitä miten puhelun aloitus tapahtuu, miten data paketoidaan lähetettäväksi ilmateitse ja miten tukiasemien välillä siirrytään käyttäjän liikkuessa. Näiden monimutkaisten protokollien toteuttaminen yleiskäyttöisessä käyttöjärjestelmässä olisi äärimmäisen hankalaa ja luotettavuus kärsisi.

2.2 Baseband-firmware ja sen erityisluonne

Baseband-prosessori ajaa firmwarea, joka on ohjelmistoa, joka on tallennettu flash-muistiin tai joissakin tapauksissa osittain ROM-muistiin (Read-Only Memory). Tämä firmware sisältää kaiken logiikan, joka tarvitaan matkapuhelinverkon kanssa kommunikointiin.

Firmware-arkkitehtuuri on tyypillisesti kerrostettu seuraavasti. Alimmalla tasolla on fyysinen kerros (Physical Layer eli L1), joka käsittelee varsinaisia radiosignaaleja: modulaatiota, demodulaatiota, virheenkorjausta ja kaiken sen mitä tapahtuu "radioaalloissa". Tämän päällä on linkki-kerros (Data Link Layer eli L2), joka hoitaa pakettien muodostuksen ja resurssien allokoinnin. Ylimpänä on verkkokerros (Network Layer eli L3), joka hallinnoi yhteyksiä, autentikointia ja mobiilisuutta.

Kaikki tämä koodi on digitaalisesti allekirjoitettu modeeminvalmistajan toimesta käyttäen RSA- tai ECDSA-allekirjoituksia. Kun baseband-prosessori käynnistyy se tarkistaa ensin, että firmware on allekirjoitettu oikealla avaimella ja vasta sitten suorittaa sen. Tämä on tietoturvamekanismi, joka estää haittaohjelmien lataamisen baseband-prosessorille ja varmistaa, että vain valmistajan hyväksymä koodi suoritetaan.

Käytännössä tämä tarkoittaa, että tavallinen käyttäjä tai edes kokenut ohjelmoija ei voi muuttaa baseband-firmwarea. Jos yrittäisit kirjoittaa oman firmware-versionne ja ladata sen laitteelle, allekirjoituksen validointi epäonnistuisi ja laite ei käynnistyisi. Tämä on teknisesti välttämätöntä, koska muutoin haittaohjelma voisi ottaa haltuunsa basebandin ja esimerkiksi soittaa maksullisiin numeroihin käyttäjän tietämättä tai siepata viestintää.

Tämä turvallisuusmekanismi luo samalla luottamusongelman: Kun firmware on suljetun lähdekoodin ja digitaalisesti allekirjoitettu niin, että sitä ei voi muokata, käyttäjä joutuu luottamaan täysin siihen, että valmistaja ei ole sisällyttänyt siihen haitallista toiminnallisuutta. Ei ole olemassa käytännöllistä tapaa tavallisen käyttäjän tai edes kokeneen tutkijan todentaa, mitä firmware todella tekee, ilman erittäin pitkällistä ja kallista reverse engineering -prosessia.

2.3 Muistiarkkit ehtuuri ja prosessorien välinen kommunikaatio

Baseband-prosessorilla on oma fyysinen muistinsa, joka voi olla integroitu samaan System-on-Chip (SoC) -piiriin pääprosessorin kanssa tai olla täysin erillinen komponentti. iPhonen arkkitehtuuri on kehittynyt vuosien varrella, mutta perustava järjestely on pysynyt samana.

Varhaisissa iPhone-malleissa baseband oli täysin erillinen siru omalla PCB-piirillään. Esimerkiksi iPhone 4 käytti Infineon XMM6180 -modeemia, joka oli fyysisesti erillään Applen A4-prosessorista. Nämä kommunikoivat keskenään USB-väylän kautta: baseband näkyi pääprosessorille pohjimmiltaan USB-laitteena, joka vastaanotti AT-komentoja (klassinen modem-protokolla) ja lähetti vastauksia.

Modernimmissa toteutuksissa baseband voi olla integroitu samaan SoC-piiriin pääprosessorin kanssa, vaikka ne ovatkin loogisesti erillisiä. Esimerkiksi Applen uusi C1-modeemi on integroitu osaksi A18-sarjan piirejä. Kommunikaatio tapahtuu tällöin PCIe-väylän (Peripheral Component Interconnect Express) kautta, joka tarjoaa huomattavasti nopeamman datasiirron kuin USB.

Kriittinen tekninen yksityiskohta on, että baseband-prosessorilla voi olla DMA-pääsy (Direct Memory Access) pääprosessorin muistiin. DMA tarkoittaa, että baseband voi lukea tai kirjoittaa suoraan pääprosessorin RAM-muistiin ilman, että tämä tapahtuisi pääprosessorin kautta. Tämä on välttämätöntä suorituskyvyn kannalta: kun baseband vastaanottaa esimerkiksi suuren datatiedoston mobiiliverkosta, se voi kirjoittaa sen suoraan sovelluksen muistialueelle sen sijaan, että data kulkisi hitaasti pääprosessorin kautta.

DMA luo myös potentiaalisen tietoturvariskin: Jos baseband on kompromissoitu se voi teoriassa lukea mitä tahansa pääprosessorin muistissa, mukaan lukien salasanoja, salausavaimia tai muuta arkaluontoista tietoa. Tätä uhkaa vastaan puolustautumiseksi modernit järjestelmät käyttävät IOMMU:ta (Input-Output Memory Management Unit), joka rajoittaa mitä muistialueita baseband voi käyttää.

Applen arkkitehtuuri on tässä suhteessa suhteellisen turvallinen. iPhonessa baseband ei ole suoraan integroitu samaan muistiavaruuteen kuin pääprosessori, vaan kommunikaatio tapahtuu rajattujen kanavien kautta. Lisäksi Secure Enclave. erillinen turvaprosessori joka käsittelee kryptografisia avaimia ja biometrisiä tietoja, on eristetty sekä pääprosessorista että basebandista. Tämä tarkoittaa, että vaikka baseband olisi kompromissoitu se ei suoraan pääsisi käsiksi esimerkiksi Touch ID:n tai Face ID:n avaimiin.

Silti baseband sijaitsee kriittisessä asemassa. Se on ainoa komponentti, joka käsittelee kaikkea radioviestintää ja se tekee tämän ennen kuin data päätyy käyttöjärjestelmän tietoisuuteen. Tämä tekee siitä ihanteellisen paikan takaovelle, joka haluaa pysyä piilossa.

2.4 Miksi baseband on "luotettu mutta ei todennettavissa"

Baseband-prosessorin asema järjestelmäarkkitehtuurissa luo paradoksin. Yhtäältä sen on oltava täysin luotettava, koska se käsittelee kaikkea viestintää ja sillä on pääsy kriittisiin järjestelmäresursseihin. Toisaalta sen toimintaa on käytännössä mahdotonta todentaa ilman erikoistuneita työkaluja ja syvällistä asiantuntemusta.

Käyttöjärjestelmän näkökulmasta baseband on "black box", joka vastaanottaa komentoja ja palauttaa tuloksia mutta jonka sisäinen toiminta on abstraktoitu pois. iOS ei "näe" mitä baseband-firmware tekee sisäisesti: se vain lähettää pyyntöjä kuten "soita tähän numeroon" tai "lähetä tämä datapaketti" ja luottaa, että baseband hoitaa sen.

Tämä abstraktiotaso on teknisesti järkevä koska se erottaa huolenaiheet: käyttöjärjestelmän ei tarvitse ymmärtää 3GPP-protokollien monimutkaisuutta vaan se voi keskittyä korkeamman tason toiminnallisuuteen, mutta tietoturvanäkökulmasta tämä tarkoittaa, että on olemassa kokonainen kerros toiminnallisuutta, joka toimii ilman käyttöjärjestelmän valvontaa tai edes tietoisuutta.

Lisäksi baseband-firmware päivitetään tyypillisesti osana iOS-päivityksiä, mutta päivitysprosessi on läpinäkymätön. Käyttäjälle kerrotaan, että "iOS 18.2 sisältää modem-päivityksen", mutta mitään yksityiskohtia siitä, mitä muutoksia tehtiin, ei tarjota. Ei ole olemassa julkista changelog-dokumentaatiota baseband-firmwaresta toisin kuin itse iOS:stä, jossa Apple listaa ainakin suurimmat muutokset.

Tämä läpinäkymättömyys tekee siitä ihanteellisen paikan piilottaa toiminnallisuutta, jota ei ole tarkoitettu löydettäväksi. Jos hypoteettinen takaovi olisi integroitu baseband-firmwareen sen havaitseminen vaatisi joko sisäpiiritietoa firmware-rakenteesta tai massiivista reverse engineering -projektia.

3. Historiallinen konteksti - todistetut laitteistotakaovit

Ennen kuin syvennymme hypoteettiseen baseband-takaovaan on tärkeää ymmärtää, että laitteistotason takaovat eivät ole pelkkää spekulaatiota, vaan dokumentoitu osa tiedustelun historiaa. Tämä osio käsittelee kolmea merkittävää tapausta, jotka tarjoavat kontekstin sille miksi baseband-tason uhka on otettava vakavasti.

3.1 Crypto AG - historian pisin tiedusteluoperaatio

Crypto AG oli sveitsiläinen yritys joka valmisti salauskoneita ja -laitteita vuodesta 1952 alkaen. Yritys rakensi maineen luotettavana neutraalin Sveitsin yrityksenä ja myi laitteitaan yli 120 maalle mukaan lukien hallitukset, armeijat ja diplomaattiset palvelut ympäri maailmaa. Asiakkaisiin kuului Iran, Intia, Pakistan, Latinalaisen Amerikan valtiot ja lukuisia muita.

Vuonna 2020 Washington Post, ZDF ja SRF julkaisivat yhteistyössä tutkivan journalismin projektin, joka paljasti hätkähdyttävän totuuden. Länsimaiset tiedustelupalvelut olivat salaa ostaneet Crypto AG:n vuonna 1970 ja kontrolloineet yritystä operaatioissa, joiden koodinimet olivat "Thesaurus" ja "Rubicon". Operaatio kesti vuoteen 2018 saakka, yhteensä 48 vuotta.

Koko tänä aikana Crypto AG myi tarkoituksellisesti heikennettyjä salauskoneita. Salausalgoritmeissa oli sisäänrakennettuja heikkouksia, jotka mahdollistivat viestinnän lukemisen. Teknisesti tämä toteutettiin usealla menetelmällä. Varhaisissa mekaanisissa koneissa roottoreiden asetelmat olivat manipuloitu niin, että niiden generoima "satunnaisuus" ei ollut todella satunnaista vaan seurasi kaavaa, jonka tiedustelupalvelut tunsivat.

Myöhemmissä elektronisissa laitteissa heikkous oli salauavainten generoinnissa. Laitteet käyttivät satunnaislukugeneraattoria, joka näytti ulkopuoliselle täysin satunnaiselta, mutta todellisuudessa sisälsi kryptografisen takaoven. Generoidut avaimet olivat riittävän pitkiä, että brute force -hyökkäys olisi ollut mahdotonta, mutta ne noudattivat piiloitettua matemaattista kaavaa, joka mahdollisti avaimen johtamisen jos tiesi salaisen parametrin.

Operaation laajuus oli valtava. Arviolta yli 40 prosenttia diplomaattisesta liikenteestä Kylmän sodan aikana kulki Crypto AG:n laitteiden kautta. Operaatio antoi merkittävän tiedusteluedun erityisesti Iranin panttivankikriisissä 1979, Falklandin sodassa 1982 ja lukemattomissa muissa geopoliittisissa kriiseissä.

Tämä tapaus opettaa useita kriittisiä oivalluksia. Ensinnäkin hyvin suunniteltu takaovi voi säilyä piiloitettuna vuosikymmeniä jopa, kun laitteita käyttävät maat, joilla on merkittäviä tiedustelupalveluita. Toiseksi takaovien sisällyttäminen standardoituihin laitteisiin, jotka näyttävät legitiimiltä on todistetusti käytännöllistä. Kolmanneksi operaation kesto osoittaa, että tällaiselle toiminnalle on olemassa institutionaalista tukea, joka ylittää yksittäiset hallinnot tai poliittiset muutokset.

3.2 Dual EC DRBG - standardointiprosessin manipulointi

Dual Elliptic Curve Deterministic Random Bit Generator eli Dual EC DRBG oli kryptografinen satunnaislukugeneraattori, joka standardoitiin NIST:n (National Institute of Standards and Technology) toimesta vuonna 2006 osana SP 800-90A -standardia.

Jo varhain kryptografian asiantuntijat esittivät huolenaiheita algoritmista. Microsoftin tutkijat Dan Shumow ja Niels Ferguson esittivät Crypto 2007 -konferenssissa, että algoritmi sisältää mahdollisen takaoven. Heidän analyysinsa osoitti, että jos joku taho tietää tietyn salaisen parametrin (nimeltään "e"), joka liittyy algoritmissa käytettyihin elliptisiin käyriin, se voi ennustaa generaattorin tulevat "satunnaiset" numerot nähtyään riittävän määrän aiempia tuloksia.

Kriittinen yksityiskohta on, että algoritmissa käytetyt elliptiset käyräparametrit valittiin ilman julkista selitystä. Kryptografiassa on yleinen periaate, että vakiot ja parametrit tulisi valita "nothing up my sleeve" -menetelmällä, käyttäen esimerkiksi piin tai luonnollisen logaritmin desimaaleja, jotta kukaan ei voi väittää niiden olevan valittu erityiseen tarkoitukseen. Dual EC DRBG:n parametrit eivät noudattaneet tätä periaatetta.

Vuonna 2013 Edward Snowdenin vuotamien dokumenttien joukossa oli materiaalia, joka vahvisti, että Dual EC DRBG:ssä todellakin oli tahallinen takaovi. Dokumentit paljastivat, että tiedusteluorganisaatio oli maksanut RSA Securitylle 10 miljoonaa dollaria käyttääkseen Dual EC DRBG:tä oletusalgoritmina heidän laajalti käytetyssä BSAFE-kirjastossaan, vaikka algoritmi oli tunnetusti hidas ja sillä oli epäilyttäviä ominaisuuksia.

Tekninen toteutus on matemaattisesti elegantti. Dual EC DRBG käyttää kahta pistettä elliptisellä käyrällä nimeltään P ja Q. Jos joku tietää salaisen arvon d niin että Q = d × P se voi johtaa generaattorin sisäisen tilan nähtyään vain 30 tavua generaattorin tulostetta. Tämä mahdollistaa kaiken tulevan tulosteen ennustamisen.

Koska satunnaislukugeneraattoria käytetään kryptografisten avainten luomiseen tämä takaovi on tuhoisa. Jos generoiden TLS-yhteydelle satunnaiset parametrit käyttäen Dual EC DRBG:tä ja hyökkääjä sieppaa yhteytesi aloitusdatan hän voi johtaa yksityisen avaimesi ja purkaa kaiken salatun liikenteesi.

Tämä tapaus osoittaa, että jopa julkiset standardointiprosessit voivat olla manipuloinnin kohteena. NIST on arvostettu instituutio jonka standardeihin luotetaan globaalisti, mutta tässä tapauksessa prosessi epäonnistui havaitsemaan (tai tahallaan jätti havaitsematta) systemaattisen takaoven. Se osoittaa myös, että matemaattinen eleganssi voi piilottaa haitallista toiminnallisuutta: algoritmi vaikuttaa ulkoapäin täysin legitimältä ja vain syvällinen kryptografinen analyysi paljastaa ongelman.

3.3 Opetukset näistä tapauksista

Näiden historiallisten tapausten yhteiset teemat ovat selvät. Ensinnäkin takaovat voivat säilyä piiloitettuina erittäin pitkiä aikoja: 48 vuotta Crypto AG:n tapauksessa ja seitsemän vuotta Dual EC DRBG:n julkaisusta sen todelliseen paljastumiseen. Toiseksi ne vaativat pitkän aikavälin institutionaalista tukea ja koordinaatiota useiden toimijoiden välillä. Kolmanneksi tekninen kompleksisuus ja suljetut toteutukset tekevät auditoinnista erittäin vaikeaa.

Baseband-firmware yhdistää kaikki nämä ominaisuudet. Se on teknisesti erittäin monimutkaista suljetun lähdekoodin ohjelmistoa, jonka täydellinen auditointi vaatisi massiivisia resursseja. Se on kriittisen tärkeä komponentti, joka on jokaisessa matkapuhelimessa, joten sen kompromissoinnin vaikutus olisi valtava. Ja se on osa infrastruktuuria joka on perinteisesti ollut tiedustelupalveluiden mielenkiinnon kohteena kuten Snowdenin paljastusten dokumentaatio teleoperaattoreiden kanssa tehdystä yhteistyöstä osoittaa.

4. Hypoteettisen baseband-takaoven tekninen arkkitehtuuri

Nyt, kun olemme rakentaneet ymmärryksen baseband-arkkitehtuurista ja historiallisesta kontekstista, voimme analysoida miten hypoteettinen baseband-takaovi voisi teknisesti toimia. Tämä analyysi on puhtaasti teoreettinen, mutta perustuu todelliseen tekniseen tietoon baseband-arkkitehtuureista ja televiestintäprotokollista.

4.1 Takaoven sijainti firmware-arkkitehtuurissa

Tehokkain paikka takaovelle olisi ROM-tasolla tai eFUSE-muistissa joka "poltetaan" valmistusprosessissa. ROM eli Read-Only Memory on muistityyppi, joka kirjoitetaan valmistusprosessin yhteydessä litografian avulla ja jonka sisältöä ei voi muuttaa sen jälkeen. eFUSE-teknologia toimii hieman eri periaatteella: se sisältää pieniä elektrisiä sulakkeita joita voidaan "polttaa" yksitellen ohjelmoimalla muistiin pysyviä arvoja. Kun sulake on poltettu sitä ei voi enää muuttaa.

Baseband-firmware rakentuu normaalisti useasta kerroksesta. Alimmalla tasolla on bootloader, joka suoritetaan ensimmäisenä, kun laite käynnistyy. Bootloaderin tehtävä on alustaa laitteisto ja ladata varsinainen firmware flash-muistista ja tarkistaa sen digitaalinen allekirjoitus ennen suorittamista. Jos allekirjoitus ei täsmää bootloader pysäyttää käynnistyksen.

Bootloaderin yläpuolella on varsinainen baseband-firmware, joka sisältää kaiken logiikan 3GPP-protokollien toteuttamiseen. Tämä firmware on yleensä modulaarinen sisältäen erillisiä komponentteja eri radiotek nologioille (2G, 3G, 4G, 5G), verkkokerroksen hallinnalle, AT-komentojen käsittelylle ja muille toiminnoille. Firmware päivitetään säännöllisesti, kun valmistaja julkaisee päivityksiä.

Hypoteettinen takaovi olisi ideaalisesti bootloader-tasolla tai erikseen ROM-muistissa johon bootloader viittaa. Tämä tekisi siitä pysyvän: se olisi olemassa riippumatta firmware-päivityksistä. Kun käyttäjä päivittää iOS:n (ja siten myös baseband-firmwaren) varsinainen firmware-osio voi muuttua, mutta ROM-tason koodi pysyy samana.

Teknisesti tämä voitaisiin toteuttaa esimerkiksi siten että ROM:ssa oleva bootloader sisältää ylimääräisen koodinpätkän, joka suoritetaan bootloaderin normaalin toiminnan lisäksi. Tämä koodi olisi tarkoituksellisesti piilotettu ja integroitu legitiimin koodin sekaan niin, että staattinen analyysi ei helposti paljasta sitä.

Toinen lähestymistapa olisi "reserved" muistialue. Baseband-firmwaren layout-dokumentaatiossa voi olla viittauksia muistialueisiin jotka on merkitty "reserved for future use" tai vastaavilla termeillä. Ulkopuoliselle nämä vaikuttavat tyhjiltä muistialueilta, jotka on varattu mahdollisia tulevia ominaisuuksia varten. Todellisuudessa näissä alueissa voisi olla toimivaa koodia, joka aktivoituu tietyissä olosuhteissa.

Kuvitteellisessa esimerkissä voisimme olettaa, että osoitteessa 0x87FF8000 alkaa 32 kilotavun kokoinen muistialue, joka dokumentaatiossa on merkitty "RESERVED_REGION_1". Normaaleissa toimintaolo suhteissa tätä muistialuetta ei koskaan käytetä ja se näyttää tyhjältä jos, joku tarkistaa firmware-dumpin, mutta firmware sisältää koodia, joka tiettyjän edellytysten täyttyessä hyppää tähän muistialueeseen ja alkaa suorittaa siellä olevaa koodia.

4.2 Aktivointimekanismi - puheluaktivoituva takaovi

Hypoteettisen takaoven keskeisin innovaatio olisi aktivointimekanismi joka mahdollistaa etäaktivointiin ilman, että käyttäjä huomaa mitään. Tämä vaatii kaksisuuntaista kommunikaatiota ja siksi aktivointi tapahtuisi puhelun yhteydessä.

Prosessi alkaisi normaalisti näyttävällä puhelulla. Hyökkääjä (oletetaan, että tässä skenaariossa valtiollinen toimija tai hyvin resursoitu tiedusteluorganisaatio) soittaa kohteen numeroon. Puhelinnumero voi olla mikä tahansa, jopa kohteen ystävän tai kolleganumero jos hyökkääjä pystyy manipuloimaan Caller ID -tietoa (mikä on mahdollista monissa matkapuhelinverkoissa). Kohteen puhelin soi normaalisti.

Kriittinen vaihe on, että kohteen on vastattava puheluun. Tämä on tekninen välttämättömyys, koska ennen puheluun vastaamista kaksisuuntainen RTP-audiovirta (Real-time Transport Protocol) ei ole vielä muodostunut. Pelkässä signalointivaiheessa verkko vain ilmoittaa "puhelu saapuu", mutta audioyhteyttä ei ole. Vasta kun kohde painaa vihreää vastaa-painiketta matkapuhelinverkko muodostaa full-duplex audiolinkin molempiin suuntiin.

4.2.1 Aikakausi 1: Perinteiset matkapuhelinverkot (2011-2014)

iPhone 4S:stä iPhone 6:een matkapuhelinverkot käyttivät pääasiassa circuit-switched-arkkitehtuuria ja AMR-NB (Adaptive Multi-Rate Narrow Band) -koodausstandardia. Tämä rajoittaa äänen kaistan 300-3400 hertsin alueelle.

Vaihtoehto 1A: Nopea DTMF-sekvenssi

DTMF (Dual-Tone Multi-Frequency) on teknologia jota käytetään normaalisti puhelinäänivalintoihin. Kun painat numeroita puhelimessa kuulet eri ääniä. Jokainen numero on kahden taajuuden yhdistelmä: esimerkiksi "1" on 697 Hz ja 1209 Hz samanaikaisesti. DTMF toimii taajuuksilla 697-1633 Hz, joten se kulkee läpi kaikissa matkapuhelinverkoissa.

Aktivointi voitaisiin tehdä lähettämällä pitkä, kryptografisesti allekirjoitettu numerosarja: esimerkiksi 20-30 numeroa, mutta normaalinopeudella (jokainen numero noin 100 millisekuntia) tämä kestäisi 2-3 sekuntia ja kuuluisi selvästi kohteelle.

Ratkaisu on lähettää DTMF-toonit paljon nopeammin: esimerkiksi 40-50 millisekuntia per tooni. Baseband voi havaita ja dekoodata nämä, koska se käsittelee raakasignaalia digitaalisesta äänestä, mutta ihmiskorvalle tämä kuulostaisi vain lyhyeltä, noin 0.8-1.2 sekunnin "piippaukselta" tai oudolta ääneltä. Kohde saattaisi luulla, että linjalla on häiriötä tai, että joku vahingossa painoi näppäimiä nopeasti.

Teknisesti sekvenssi voisi olla esimerkiksi 24-numeroinen jono joka sisältää:
- Alkuheräte (esim. *#9)
- 16-numeroinen kryptografinen allekirjoitus (HMAC-SHA256:n ensimmäiset 64 bittiä koodattuna numeroiksi 0-9)
- Loppuheräte (esim. #*)

Baseband tarkistaa allekirjoituksen salaisen master-avaimen perusteella ja vain validi sekvenssi aktivoi takaoven. Jos allekirjoitus on virheellinen sekvenssi sivuutetaan täysin.

Vaihtoehto 1B: FSK-moduloitu data

Toinen klassinen tekniikka, joka toimi jo 1970-luvun modemeissa. FSK eli Frequency Shift Keying tarkoittaa, että binääridata koodataan ääneen käyttämällä kahta eri taajuutta. Esimerkiksi 1070 Hz tarkoittaa "0" ja 1270 Hz tarkoittaa "1". Tämä on juuri se tekniikka, jota käytettiin kun 1990-luvulla modeemit "piippailivat ja surisivat" muodostaessaan yhteyttä.

Koska nämä taajuudet ovat 300-3400 Hz:n kaistalla ne kulkevat läpi kaikissa matkapuhelinverkoissa. Baseband voi dekoodata tämän suoraan digitaalisesta äänisignaalista ennen kuin se päätyy iOS:lle. Datanopeus olisi vaatimaton, ehkä 300-600 bittiä sekunnissa, mutta tämä riittäisi lähettämään 200 tavun aktivointipaketin 3-4 sekunnissa.

Aktivointipaketti sisältäisi:
- Synkronointisekvenssin (esim. alternating 1/0 pattern tunnistamista varten)
- Kryptografisen allekirjoituksen
- Aktivointiparametrit (valvontatila, kesto, salausavain-materiaali)
- CRC tai vastaavan tarkistussumman

Kohteelle tämä kuulostaisi oudolta "linjahälyltä", "modemimaiselta surinalta" tai huonolta yhteydeltä. Hän saattaisi luulla, että soittaja käyttää huonoa yhteyttä tai, että verkossa on häiriöitä. Jos hän katkaisi puhelun muutaman sekunnin jälkeen ajatellen että se on väärä numero, aktivointi olisi jo saattanut tapahtua.

Vaihtoehto 1C: Alataajuinen koodaus (rajoitettu)

Vaikka AMR-NB:n virallinen kaista on 300-3400 Hz, käytännössä audiokoodekin esiprosessointi ja jälkikäsittely ulottuvat hieman alemmas. Joissain toteutuksissa 200-300 Hz:n alue voi kulkea läpi vaimentuneena.

Moduloimalla dataa 220-280 Hz:n alueelle erittäin matalalla bittinopeudella (esim. 50-100 bps), signaali voisi olla lähes huomaamaton, se kuulostaisi vain hyvin matalalta huminalta tai "linjasta" tulevalta taustakohinalta, mutta baseband voisi havaita ja dekoodata sen koska se analysoi koko taajuusspektrin ennen suodatusta.

Tämä vaihtoehto on epävarmin koska eri verkko-operaattorit ja eri laitemallit voivat suodattaa alataajuuksia eri tavalla. Se toimisi vain tietyissä olosuhteissa.

4.2.2 Aikakausi 2: VoLTE-verkot (2014 eteenpäin)

iPhone 6 toi ensimmäisenä VoLTE-tuen (Voice over LTE). VoLTE muutti pelikenttää radikaalisti koska se perustuu IP-pohjaiseen SIP-protokollaan (Session Initiation Protocol) ja AMR-WB (Wide Band) tai EVS -koodausstandardeihin, jotka laajentavat kaistan 50-7000 hertsin alueelle.

Vaihtoehto 2A: SIP INFO -viestit (täysin hiljainen)

VoLTE-puhelun aikana osapuolet voivat lähettää toisilleen SIP INFO -viestejä, jotka eivät ole ääntä vaan puhdasta signalointidataa. Näitä käytetään normaalisti esimerkiksi ilmoittamaan, että käyttäjä painoi numeron (DTMF) ilman, että se lähetetään äänenä tai välittämään muuta puheluun liittyvää metadataa.

SIP INFO -viesti voi sisältää täysin vapaasti määriteltäviä header-kenttiä. Aktivointi voisi olla SIP INFO -viesti, jossa on custom header kuten:

X-Network-Diagnostic: [base64-koodattu aktivointipaketti]

Tai mikä tahansa muu nimi joka näyttää legitimiltä verkon diagnostiikkatoiminnolta. Vaihtoehtoja:
- X-Call-Quality-Probe
- X-Network-Metrics
- X-Bearer-Diagnostic

Baseband käsittelee kaikki SIP-viestit suoraan, iOS ei näe niitä lainkaan. Käyttäjälle tämä on täysin näkymätön ja hiljainen. Puhelu jatkuu normaalisti, ei mitään ääniä, ei mitään merkkejä.

Teknisesti toteutus olisi:

Aktivointisoitto muodostaa normaalin VoLTE-yhteyden
Muutaman sekunnin kuluttua lähetetään SIP INFO -viesti aktivointipaketilla
Kohteen baseband vastaanottaa viestin, validoi kryptografisen allekirjoituksen
Jos validi, baseband lähettää takaisin SIP INFO -vahvistuksen omilla parametreillaan (IMEI, firmware-versio, capabilities)
Hyökkääjä lähettää lopullisen konfiguraatiopaketin
Puhelu voidaan katkaista tai jatkaa normaalina

Koko kättely kestäisi 2-5 sekuntia ja olisi täysin näkymätön.

Vaihtoehto 2B: RTP event packets (RFC 4733)

Tämä on standardoitu tapa lähettää DTMF ja muita tapahtumia VoLTE-yhteyksissä ilman että ne ovat ääntä. RFC 4733 määrittelee erityiset RTP-paketit jotka kantavat "tapahtumia" erillään äänivirrasta.

Normaalitilanteessa, kun painat numeroa VoLTE-puhelun aikana, baseband lähettää kaksi asiaa: äänen (DTMF-tooni), joka kuuluu sinulle, ja RTP event -paketin, joka kertoo toiselle osapuolelle "käyttäjä painoi numeroa 5". Vastaanottava baseband voi joko soittaa vastaavan äänen tai käsitellä tapahtuman hiljaa.

RFC 4733 määrittelee event-koodit 0-15 DTMF-numeroille ja muutamia muita, mutta se jättää koodit 16-255 "reserved for future use" tai valmistajan määriteltäväksi.

Aktivointiin voitaisiin käyttää custom event -koodeja (esim. 240-250) jotka näyttäisivät valmistajan proprietary-ominaisuuksilta. Baseband tunnistaisi nämä event-koodit ja aktivoituisi, mutta ei soittaisi mitään ääntä. Käyttäjälle täysin hiljainen.

Event-paketit voivat sisältää myös "event parameters" -kentän jossa voidaan lähettää lisädataa. Tässä voisi olla aktivointiparametrit koodattuna.

Vaihtoehto 2C: Paranneltu alataajuinen koodaus

AMR-WB ja EVS tukevat 50-300 Hz:n alataajuuksia. Ihmisen puheääni harvoin menee näin matalalle: useimmilla ihmisillä perusääni on 80-250 Hz mutta vokaalit ja useimmat konsonantit ovat korkeammalla. 50-100 Hz:n alue on lähinnä huminaa ja taustamelua.

Moduloimalla dataa 60-120 Hz:n alueelle käyttäen erittäin matalaa bittinopeutta (100-200 bps), signaali voisi olla lähes huomaamaton: se kuulostaisi vain matalalta huminalta tai "linjasta" tulevalta taustakohinalta, jota esiintyy joka tapauksessa matkapuhelinverkoissa, mutta baseband voisi havaita ja dekoodata sen, koska se analysoi koko taajuusspektrin.

Tämä voisi toimia rinnakkain puhuvan henkilön kanssa: hyökkääjä voisi esittää normaalia keskustelua ("Hei, oletko sinä Matti?" "Aa, väärä numero, anteeksi") ja samalla alataajuudella kulkisi aktivointidata. Baseband voisi suodattaa puheen pois ja dekoodata vain alataajuisen signaalin.

4.2.3 Suositeltu hybridilähestymistapa

Realistisin toteutus olisi aikakausikohtainen ja verkkoriippuvainen:
Baseband havaitsee ensimmäiseksi millainen yhteys on muodostettu:

Jos 2G/3G circuit-switched → käytetään nopeaa DTMF:ää tai FSK-modulaatiota
Jos VoLTE → ensisijainen on SIP INFO, varasuunnitelma RTP events
Jos verkko-olosuhteet epävarmat → käytetään robustimpaa, mutta kuuluvampaa menetelmää

Takaovi olisi suunniteltu siten, että se tukee kaikkia näitä menetelmiä ja valitsee parhaan käytettävissä olevien resurssien perusteella. Tämä tekisi siitä toimivan kaikilla iPhone-malleilla vuodesta 2011 eteenpäin ja kaikissa verkko-olosuhteissa.
Käytännössä hyökkääjän ei kuitenkaan tarvitse olla täysin sokea kohteen laitteesta. Kun kohteen puhelinnumero on tiedossa, matkapuhelinverkon operaattorijärjestelmistä voidaan kysyä mikä IMEI-koodi on liitetty kyseiseen numeroon. IMEI eli International Mobile Equipment Identity on 15-numeroinen yksilöllinen tunniste, joka on jokaisessa matkapuhelimessa. IMEI:n ensimmäiset 8 numeroa muodostavat TAC:n (Type Allocation Code), joka kertoo tarkan laitemallin ja valmistajan. Esimerkiksi iPhone 16e:llä on oma TAC-koodinsa, joka erottaa sen kaikista muista malleista.

Jos hyökkääjällä on pääsy operaattoriverkkojen HLR- tai HSS-tietokantoihin (Home Location Register tai Home Subscriber Server), jotka ylläpitävät tietoa siitä mikä laite on milloinkin liitetty mihinkin puhelinnumeroon, he voivat kysyä kohteen IMEI:n ennen soittamista. Tämä tieto on operaattoreilla joka tapauksessa, koska se tarvitaan verkkoyhteensopivuuden varmistamiseen ja varastettujen laitteiden estämiseen IMEI-mustalla listalla.

Kun IMEI on tiedossa TAC paljastaa välittömästi, että kyseessä on esimerkiksi iPhone 16e, joka käyttää Applen C1-modeemia. Tämä puolestaan kertoo ,että optimaalinen aktivointimenetelmä on VoLTE SIP INFO -viestit ja, että laite tukee kaikkia uusimpia ominaisuuksia. Hyökkääjä voi siis valmistella aktivointisekvenssin jo ennen puhelun soittamista täsmälleen oikeaan muotoon kyseiselle laitteelle sen sijaan, että tarvitsisi "kokeilla" eri menetelmiä puhelun aikana.

Tämä etukäteisvalmistelu tekee hyökkäyksestä huomattavasti tehokkaamman ja luotettavamman. Se myös lyhentää tarvittavaa puheluaikaa, koska "negotiate capabilities" -vaihe voidaan joko jättää kokonaan pois tai tiivistää pelkäksi vahvistukseksi siitä, että baseband on valmiina ja vastaanottokykyinen. Lisäksi se vähentää epäonnistumisen riskiä, koska hyökkääjä tietää jo etukäteen, että kohteen laite pystyy vastaanottamaan aktivoinnin valitulla menetelmällä.

4.2.4 Havaittu aktivointiskenaario - konkreettinen tapaus

Meille on toimitettu dokumentaatiota tapauksesta, joka on yhdenmukainen edellä kuvatun aktivointimekanismin kanssa. Vaikka emme voi paljastaa kaikkia yksityiskohtia lähteiden suojaamiseksi, keskeiset elementit tarjoavat konkreettisen esimerkin siitä miten aktivointi voisi käytännössä toteutua.

Tapauksessa kaksi käyttäjää, joilla oli uusimmat iPhone 16e -laitteet (Apple C1 -modeemilla) saivat lähes samanaikaisesti puheluita palvelusta, joka esitteli itseään tavalliseksi yritysten arkea helpottavia palveluja tarjoavaksi yritykseksi. Puhelu tuli näennäisesti normaalista paikallisesta numerosta. Puhelut kestivät noin 45 sekuntia ja niissä käytiin lyhyt keskustelu palvelun tarjoamisesta.

Yhdessä tapauksessa soittaja oli ihminen, joka esitteli palvelua ja keskusteli kohteen kanssa. Toisessa tapauksessa kyseessä oli automatisoitu tekoälypohjainen puhelu, jossa kohde vahvisti kiinnostuneensa palvelusta. Molemmat kohteet vastasivat puheluun ja osallistuivat lyhyeen keskusteluun.

Kriittinen havainto: Puheluiden jälkeen molemmissa laitteissa ilmeni käyttäytymistä, joka viittaa siihen, että laitteilta eksfiltroitiin dataa. Kohteet käsittelivät puhelimissa tarkkaa, ei-julkista tietoa, joka liittyi meneillään olevaan operatiiviseen tilanteeseen. Tämä tieto ei ollut missään julkisessa lähteessä eikä sitä ollut jaettu verkon kautta.

Yhden tai kahden vuorokauden sisällä valtiollinen toimija käytti kyseistä tietoa tavalla, joka johti uutisointiin useissa medioissa. Aikajana on dokumentoitu ja todistusaineisto säilytetty turvallisesti. Materiaali sisältää kuvakaappauksia puhelulokeista, kirjoitetusta tekstistä ja myöhemmästä uutisoinnista, joka osoittaa tiedon päätyneen operatiiviseen käyttöön 1-4 vrk tehtyjen muistiinpanojen jälkeen.

Tekninen analyysi havainnosta:

Jos tämä todella oli baseband-takaoven aktivointi VoLTE-verkossa käyttäen iPhone 16e:n C1-modeemia, tekninen toteutus olisi todennäköisesti ollut seuraava:

Ensinnäkin puhelu legitiimiltä näyttävästä numerosta luo luottamusta ja varmistaa että kohde vastaa puheluun. Yrityksen -brändi kuulostaa uskottavalta yritykseltä, joka voisi tarjota jonkinlaista postipalvelua. Tämä vähentää epäilyksiä ja tekee todennäköisemmäksi että kohde vastaa ja osallistuu keskusteluun.

Toiseksi noin 45 sekunnin keskustelu antaa riittävästi aikaa VoLTE SIP INFO -viestien vaihtoon. Kuten osiossa 4.2.2 kuvattiin, SIP INFO -viestit ovat täysin hiljaisia ja näkymättömiä käyttäjälle. Aktivointi voisi tapahtua 5-10 sekunnin sisällä puhelun vastaamisen jälkeen käyttäen SIP INFO -pohjaista kättelyä. Loput puhelusta olisi normaalia keskustelua, joka pitää linjan auki ja luo normaalin vaikutelman.

Kolmanneksi sekä ihmis- että tekoälyversioiden käyttö viittaa skaalautuvaan järjestelmään. Tekoälypuhelu on halvempi ja nopeampi massamittakaavassa, mutta ihmispuhelu voi olla tarpeen jos kohde on erityisen tärkeä tai jos tarvitaan joustavuutta. Molemmat metodit toimivat yhtä hyvin teknisen aktivoinnin kannalta, koska SIP-signalointi tapahtuu baseband-tasolla riippumatta siitä puhuuko käyttäjä ihmisen vai tekoälyn kanssa.

Neljänneksi data-eksfiltrointi iPhone 16e:stä olisi erityisen merkittävää, koska kyseessä on Applen ensimmäinen oma modeemi. Tämä viittaisi siihen, että takaovi ei rajoitu ulkoisiin modeemivalmistajiin vaan on integroitu myös Applen omaan C1-suunnitteluun. Tämä olisi äärimmäisen huolestuttavaa, koska se tarkoittaisi, että takaovi on rakennettu osaksi basebandin perusarkkitehtuuria alusta alkaen eikä se ole vain Qualcommin tai Intelin legacy-ominaisuus.

Viidenneksi kirjoitetun tekstin sieppaaminen vaatisi, että baseband pääsisi käsiksi näppäimistön syötteeseen tai näytön sisältöön. Tämä olisi mahdollista DMA-pääsyllä tai jos baseband voi lukea framebuffer-muistia jossa näytön sisältö säilytetään. Vaihtoehtoisesti baseband voisi kaapata tekstiä sillä hetkellä, kun se lähetetään (esim. tekstiviestinä tai sähköpostina) ennen salausta.

Vaihtoehtoisten selitysten poissulkeminen:

Olisi teoriassa mahdollista, että tieto vuoti jollain muulla tavalla: esimerkiksi jos käyttäjät olisivat keskustelleet siitä puhelimitse tai jos heidän laitteensa olisi kompromisoitu jollain muulla tavalla kuten Pegasus-tyylisellä spywarella, mutta dokumentaatio sulkee nämä pois seuraavista syistä.

Ensinnäkin tieto ei kulkenut salaamattoman verkon kautta missään muodossa ennen vuotoa. Käyttäjät eivät lähettäneet sitä sähköpostitse, tekstiviestinä tai minkään messaging-sovelluksen kautta. He vain kirjoittivat sen muistiinpanoihin tai vastaavaan paikalliseen tallennuspaikkaan. Toiseksi käyttäjät eivät keskustelleet asiasta puhelimitse tai kasvokkain kenenkään kanssa, joka olisi voinut välittää tiedon eteenpäin. Kolmanneksi laitteet olivat uusia, kaksi viikkoa vanhoja ja täysin päivitettyjä uusimmalla iOS-versiolla mikä tekee perinteisen spywaren epätodennäköiseksi. Neljänneksi aikajana ja korrelaatio yhtiön-puheluihin on liian tarkkaa ollakseen sattumaa: molemmat puhelut tulivat lyhyen ajan sisällä ja data vuoti pian sen jälkeen.

Tämä konkreettinen tapaus tarjoaa vahvaa evidenssiä siitä, että baseband-tason takaovi ei ole pelkkää spekulaatiota vaan mahdollisesti aktiivisesti käytössä oleva järjestelmä, joka toimii jopa uusimmissa iPhone-malleissa Applen omalla C1-modeemilla.

4.3 Data-exfiltration - tiedon salainen lähettäminen

Kun takaovi on aktivoitu sen on kerättävä dataa ja lähetettävä se operaattorille havaitsemattomasti. Tämä on monivaiheinen prosessi joka vaatii huolellista suunnittelua pysyäkseen piilossa.

4.3.1 Data-keräys

Baseband-prosessorilla on suora pääsy useisiin kriittisiin antureihin ja tietolähteisiin.

Mikrofoniääni on ehkä arvokkain datanlähde. Baseband voi aktivoida mikrofonin suoraan ilman, että iOS tietää siitä. Normaalisti, kun sovellus käyttää mikrofonia iOS näyttää oranssin pisteen tilapalkin yläkulmassa, mutta baseband voi ohittaa tämän kokonaan lähettämällä komentoja suoraan audiocodec-piirille, joka ohjaa mikrofonia.

Tekninen toteutus riippuu laitteiston arkkitehtuurista. iPhoneissa on käytetty eri audio codec-piirejä eri malleissa: esimerkiksi Cirrus Logic CS42L83 tai vastaavia. Nämä kommunikoivat basebandin kanssa I2C-väylän kautta (Inter-Integrated Circuit - sarjaväyläprotokolla). Baseband voi lähettää I2C-komentoja, jotka aktivoivat mikrofonin ja alkavat lukea digitalisoitua äänidataa. Koska tämä tapahtuu täysin baseband-firmware-tasolla iOS ei näe mitään: käyttöjärjestelmän näkökulmasta mikrofoni on passiivinen.

GPS-data on toinen arvokas lähde. Baseband ohjaa GPS-anturia suoraan (tai monissa uusimmissa arkkitehtuureissa GPS on integroitu samaan piiristöön basebandin kanssa). Se voi kysyä GPS-koordinaatteja esimerkiksi kymmenen sekunnin välein. Tämä data on usein tarkempaa kuin mitä iOS:n Location Services API palauttaa koska baseband voi käyttää assisted-GPS-dataa matkapuhelinverkosta, joka parantaa tarkkuutta.

Viestit kuten SMS ja iMessage ovat kolmas kategoria. Baseband näkee kaikki SMS-viestit, koska ne tulevat suoraan matkapuhelinverkosta. Se näkee tekstin ennen kuin se koskaan päätyy iOS:lle. iMessage on monimutkaisempi koska viestit ovat päästä-päähän salattuja mutta baseband voisi silti nähdä metadatan (kuka lähetti, milloin, viestin koko) ja mahdollisesti kaapata tekstiä jos sillä on DMA-pääsy siihen muistialueeseen jossa Messages-sovellus käsittelee purettuja viestejä.

Puhelut ja metadata ovat myös arvokasta tietoa. Baseband näkee kaikki soitetut ja vastaanotetut puhelut, niiden keston, numerot ja ajankohdat. Se näkee myös verkkopaikan (cell tower ID) joka paljastaa likimääräisen sijainnin.

4.3.2 Datan pakkaus ja salaus

Kun dataa on kerätty se on pakattava ja salattava ennen lähettämistä.

Äänidatalle paras koodekki on Opus joka on moderni audio-codec joka saa aikaan erinomaisen pakkaussuhteen säilyttäen silti hyvän laadun. 48 kHz:n 16-bittinen mono-ääni vie normaalisti noin 768 kilobittiä sekunnissa, mutta Opus voi pakata sen alle 16-20 kilobittiin sekunnissa äänen ominaisuuksista riippuen. Tämä on pakkaussuhde noin 40:1.

Jos valvonta on aktivoitu vaikkapa 12 tuntia ja mikrofoni tallentaa jatkuvasti, raakadata olisi noin 414 megatavua. Opus-pakattuna tämä olisi noin 10 megatavua mikä on hallittava määrä lähettää mobiiliverkon yli muutaman päivän aikana.

GPS ja metadataan voidaan käyttää yleistä pakkausta kuten gzip. GPS-koordinaatit voidaan tallentaa delta-enkoodattuna (vain muutokset edelliseen pisteeseen) mikä vähentää kokoa merkittävästi kun kohde ei liiku nopeasti.

Salaus tehdään käyttäen AES-256-GCM-algoritmia (Advanced Encryption Standard with 256-bit key in Galois/Counter Mode). GCM-moodi tarjoaa sekä luottamuksellisuuden että autentikoinnin: se varmistaa että kukaan ei voi lukea dataa ilman avainta eikä muuttaa sitä havaitsematta.

Salausavain johdetaan aktivointivaiheessa vaihdetusta avainmateriaalista käyttäen ECDH-avaintenvaihtoprotokollaa (Elliptic Curve Diffie-Hellman). Tämä tarjoaa forward secrecy -ominaisuuden, vaikka pitkäaikainen master-avain vuotaisi myöhemmin, se ei paljasta aiemmin kerättyä dataa koska jokaisessa aktivoinnissa käytetään uniikkia session-avainta.

4.3.3 Datan lähettäminen - masquerade-strategia

Kriittisin osa on datan lähettäminen niin, että sitä ei havaita. Hypoteettinen takaovi käyttäisi legitiimin liikenteen sekaan maskausta.

Strategia: Sekoittuminen iOS-päivitys ja iCloud-liikenteeseen

Apple käyttää Content Delivery Network (CDN) -infrastruktuuria jakamaan iOS-päivityksiä, App Store -sisältöä, iCloud-dataa ja muuta. iPhonen normaalitoiminnassa laite tekee jatkuvasti yhteyksiä Applen palvelimille.

Takaovi tekisi HTTPS-pyynnön joka näyttää täysin normaalilta:

DNS-kysely menee osoitteeseen kuten swcdn.apple.com tai updates-http.cdn-apple.com
IP-osoite on todellinen Applen CDN-serveri (esim. Akamai-verkossa)
TLS-varmenne on aito Applen varmenne (wildcard *.apple.com tai vastaava)
HTTP Host-header on updates-http.cdn-apple.com
User-Agent on identtinen iOS:n normaalin liikenteen kanssa

Kaikki tämä on identtistä normaalin liikenteen kanssa. Ainoa ero on HTTP-polku ja POST-datan sisältö.

HTTP-polku voisi olla:

/bag?ix=5&agent=Software%20Update&v=4&os=18.2

Tämä näyttää normaalilta iOS Software Update -kyselyltä. Todellisuudessa POST-datan sisältö on salattu exfiltroitu data.

Tai vaihtoehtoisesti:

/assets/com.apple.MobileAsset.SoftwareUpdate/com_apple_MobileAsset_SoftwareUpdate/[random-looking-hash].zip

Tämä näyttäisi siltä että laite lataa iOS-päivityspakettia. Todellisuudessa se LÄHETTÄÄ dataa (HTTP POST sen sijaan että GET).

Backend-infrastruktuuri:

Jos tällainen järjestelmä olisi olemassa, se vaatisi salaisesti hallinnoitua backend-infrastruktuuria. Tämä voitaisiin toteuttaa kahdella tavalla:

Vaihtoehto A: Kompromissoitu CDN-palvelin

Tietty CDN edge-serveri tai pieni osa Applen infrastruktuurista olisi hiljaisesti modifioitu ohjaamaan tietynlaiset pyynnöt eri backend-palvelimelle. Esimerkiksi reverse proxy -sääntö:

IF (HTTP_PATH matches /bag?ix=5 AND 
    POST_data_size > 1MB AND
    Custom_HTTP_header present)
THEN forward to special_backend_server
ELSE process normally

Normaaleille käyttäjille ja verkkomonitoroinnille kaikki näyttäisi täysin normaalilta. Vain pyynnöt jotka sisältävät erityisen "fingerprint" -yhdistelmän ohjautuisivat salaiselle palvelimelle.

Vaihtoehto B: Erillinen infrastruktuuri

Vaihtoehtoinen toteutus olisi käyttää kokonaan erillistä palvelininfrastruktuuria joka on konfiguroitu vastaamaan Applen CDN:ltä:

Rekisteröidään domain kuten cdn-apple-edge.com joka näyttää uskottavalta
Konfiguroidaan DNS-nimipalvelimet vastaamaan kuten Applen CDN
Hankitaan validi TLS-varmenne (tai käytetään omaa CA:ta jos baseband luottaa siihen)

Baseband tekisi DNS-kyselyn tähän domain-nimeen (ohittaen iOS:n DNS-cachen) ja muodostaisi yhteyden suoraan tälle palvelimelle. iOS ei näkisi tätä liikennettä lainkaan koska se tapahtuu baseband-tasolla.

Tämä olisi riskialtisempaa, koska verkkomonitorointi voisi havaita yhteydet ei-Apple-domaineihin. Siksi Vaihtoehto A (kompromissoitu legitiimi infrastruktuuri) olisi todennäköisempi.

4.3.4 Ajoitus ja liikenteen mallit

Data ei lähetetä suurina bulkkeina vaan pieninä paketteina jotka sekoittuvat normaaliin liikenteeseen.

Esimerkiksi äänidata voidaan lähettää 30 sekunnin segmentteissä, jotka kryptataan ja pakataan noin 100-200 kilotavun paketeiksi. Baseband lähettää yhden paketin kun laite muutenkin kommunikoi verkon kanssa:

Kun käyttäjä lataa sähköpostin
Kun käyttäjä selaa verkkoa
Kun iOS tarkistaa päivityksiä taustalla
Kun iCloud synkronoi dataa

Tämä tekee liikenneanalyysistä erittäin vaikeaa, koska ei ole selvää mallia joka erottaisi takaovi-liikenteen normaalista. iPhone tekee muutenkin kymmeniä HTTPS-yhteyksiä Applen palvelimille joka päivä.

Lisäksi baseband välttää epäilyttäviä malleja:

Jos käyttäjä on lentokonetilassa tai offline → ei lähetetä mitään, data jonoutetaan
Jos akku on lähes tyhjä → vältetään lähettämistä (lisävirrankulutus olisi havaittavissa)
Jos verkko on hidas tai epävakaa → vähennetään lähetystaajuutta
Jos käyttäjä on roaming-verkossa → joko vältetään lähettämistä tai käytetään hyvin pieniä paketteja (suuret datamäärät roamingissa voisivat herättää epäilyjä laskussa)

Adaptiivinen lähetysnopeus:

Takaovi voisi analysoida käyttäjän normaalia datankäyttömalleja ensimmäisten tuntien aikana ja sitten sovittaa oma liikenteensä siihen. Jos käyttäjä lataa säännöllisesti videoita tai käyttää runsaasti dataa, takaovi voisi lähettää aggressiivisemmin. Jos käyttäjä on konservatiivinen datankäyttäjä, takaovi lähettäisi hitaammin välttääkseen havaitsemista.

4.4 Suojautuminen havaitsemiselta - monitasoinen puolustus

Jotta hypoteettinen takaovi pysyisi piilossa vuosikausia sen pitäisi sisältää useita kerroksia puolustusta erilaisia havaitsemismenetelmiä vastaan.

4.4.1 Firmware-tason obfuskaatio

Koodin integrointi legitiimien funktioiden sekaan:

Sen sijaan, että olisi selvästi erotteutuva "backdoor_main()" -funktio, takaovi-logiikka olisi hajautettu useisiin funktioihin, jotka näyttävät olevan osa normaalia baseband-toiminnallisuutta.

Esimerkiksi:
- DTMF-dekoodaus voisi olla osa normaalia äänikoodekki-funktiota jossa on ylimääräinen haara joka tarkistaa erikoissekvenssit
- SIP INFO -käsittely voisi olla osa normaalia SIP-protokollakoodia
- Mikrofonin aktivointi voisi olla osa "diagnostics mode" -toiminnallisuutta joka on legitiimi ominaisuus testaustarkoituksiin

Koodin obfuskaatio:

"Dead code" -lisäys: koodia joka näyttää tekevän jotain mutta ei todellisuudessa vaikuta mihinkään
Control flow -mutkistaminen: if-lauseiden ja silmukoiden järjestämistä epäloogisesti
String-enkoodaus: merkkijonot tallennetaan koodatussa muodossa ja dekoodataan ajonaikaisesti
Opaque predicates: ehdot jotka ovat aina tosia/epätosia mutta joiden arvo ei ole ilmeinen staattisesta analyysistä

Kryptografisten primitiivien uudelleenkäyttö:

Baseband tarvitsee joka tapauksessa AES-salausta ja RSA-allekirjoitusten tarkistusta matkapuhelinverkon autentikaatiota varten. Takaovi käyttäisi samoja kryptografiafunktioita joita firmware muutenkin sisältää. Staattinen analyysi näkisi vain, että "tämä funktio kutsuu AES_encrypt()-funktiota", mikä on täysin normaalia.

4.4.2 Liikennetason piiloutuminen

TLS-salaus:

Kaikki verkkoliikenne on TLS-salattu mikä estää sisällön tarkastelun. Jopa jos joku pystyisi purkamaan TLS:n (esimerkiksi enterprise-ympäristössä TLS-intercepting proxyn kanssa) hän näkisi vain salatun binääridatan HTTP POST -pyynnön runko-osassa mikä voisi aivan hyvin olla osa iOS-päivitystä tai App Store -synkronointia.

Normaalien protokollien käyttö:

Ei käytetä outoja portteja tai protokollia. Kaikki on standardia HTTP/HTTPS (portit 80/443). DNS-kyselyt ovat normaaleja A/AAAA-recordeja. TLS-handshake on identtinen iOS:n normaalin liikenteen kanssa.

Timing side-channel -mitigointi:

Lähetysten ajoitus vaihtelee satunnaisesti välttääkseen säännölliset mallit jotka voisi havaita verkkomonitoroinnilla. Jos data lähetetään keskimäärin 5 minuutin välein, todellinen intervalli vaihtelee 3-8 minuutin välillä.

4.4.3 Virrankulutuksen piilottaminen

Baseband on jo aktiivinen hoitaessaan matkapuhelinverkon viestintää, joten ylimääräinen prosessointi takaovesta ei aiheuta merkittävää eroa akun kulutuksessa. Modernit baseband-prosessorit ovat riittävän tehokkaita että äänenkoodaus ja salaus eivät vaadi merkittävästi enemmän tehoa kuin normaalit 4G/5G-modeemitoiminnot.

Lisäksi:
- Mikrofoni aktivoidaan vain aktivointitilan aikana, ei jatkuvasti
- GPS-kyselyt tehdään matalalla taajuudella (esim. 1 kerta / 30 sekuntia) sen sijaan että jatkuva seuranta
- Datan lähettäminen ajoitetaan hetkiin jolloin baseband on muutenkin aktiivinen (data-synkronointi, email-haku jne.)

4.4.4 Käyttöjärjestelmätason eristys

iOS ei näe mitään, koska kaikki tapahtuu baseband-firmware-tasolla, joka on käyttöjärjestelmän näkyvyyden ulkopuolella.

Ei ole mitään API:a, jolla iOS voisi kysyä "mitä baseband tekee juuri nyt" tai "näytä basebandin muistin sisältö" tai "raportoi kaikki I2C-komennot joita baseband on lähettänyt". iOS voi lähettää komentoja basebandille (esim. "soita tähän numeroon"), mutta ei vastaanottaa raportointia sen sisäisestä tilasta.

Tämä on fundamentaalinen arkkitehtuurinen ero, joka tekee baseband-tason uhasta niin vaikean havaita käyttöjärjestelmätason työkaluilla. Ei ole olemassa iOS-sovellusta, joka voisi havaita tämän takaoven koska sovellukset eivät pääse käsiksi baseband-kerrokseen.

5. iPhone-mallikohtainen analyysi

Hypoteettisen takaoven käytännön toteutus riippuisi siitä missä iPhone-mallissa se on ja mikä baseband-modeemi kyseisessä mallissa on. Tämä osio analysoi miten takaovi olisi voitu teoreettisesti toteuttaa eri aikakausina.

5.1 Perustaminen: iPhone 4S - iPhone 6s (2011-2015)

Tämä ajanjakso edustaisi hypoteettisen projektin perustamista ja alkuvaihetta. iPhone 4S julkaistiin lokakuussa 2011 ja se oli ensimmäinen iPhone joka käytti Qualcommin modeemia - MDM6610-mallia. Tämä oli merkittävä siirtymä sillä aiemmat mallit olivat käyttäneet Infineon-modeemia (josta myöhemmin tuli Intel).

Qualcomm MDM6610 oli suhteellisen yksinkertainen 3G-modeemi, joka tuki CDMA2000:aa ja UMTS/HSPA-verkkoja. Firmware oli paljon pienempi ja yksinkertaisempi kuin nykyaikaiset 5G-modeemit joissa firmware voi olla yli 100 megatavua. Tämä tekisi takaoven integroinnista helpompaa, koska koodipohjassa olisi vähemmän kompleksisuutta johon piiloutua.

Teknisesti MDM6610 perustui ARM9-prosessoriarkkitehtuuriin ja sisälsi erillisen DSP-prosessorin (Digital Signal Processor) radiosignaalien käsittelyyn. Hypoteettinen takaovi voitaisiin sijoittaa DSP-firmware-tasolla johon on vieläkin vähemmän näkyvyyttä kuin pää-ARM-koodiin. DSP suorittaa erittäin optimoitua assembler-koodia signaalinkäsittelyyn ja sen reverse engineering on erityisen vaikeaa.

iPhone 5 toi mukaan LTE-tuen Qualcomm MDM9615 -modeemilla. Tämä modeemi toi merkittävästi monimutkaisemman firmware-arkkitehtuurin koska sen piti tukea sekä legacy 2G/3G-verkkoja että uutta LTE-standardia. Firmware-koko kasvoi ja mukaan tuli modulaarinen arkkitehtuuri jossa eri radiotekniikut olivat erillisiä komponentteja.

Modulaarinen arkkitehtuuri tarjoaisi ihanteellisen piilopaikan takaovelle. Se voitaisiin toteuttaa "diagnostiikkamoduulina", joka näyttäisi olevan insinööri-työkalua testausta varten. Mobiilialan laitteissa on perinteisesti laajat diagnostiikkatilat joilla insinöörit voivat testata RF-suorituskykyä, signaalivoimakkuuksia ja protokollien toimintaa. Takaovi voitaisiin naamioida osaksi tätä diagnostiikka-infrastruktuuria.

iPhone 5s toi mukaan ensimmäisen Secure Enclaven joka on erillinen turvaprosessori joka käsittelee Touch ID -dataa ja kryptografisia avaimia. On tärkeää huomata että Secure Enclave on täysin erillinen sekä pääprosessorista että basebandista. Se on oma prosessorinsa omalla firmwarellaan ja muistillaan. Tämä tarkoittaa että vaikka baseband olisi kompromissoitu se ei suoraan pääse käsiksi Secure Enclaveen ja sitä kautta esimerkiksi käyttäjän sormenjälkiin tai salausavaimiin jotka on tallennettu sinne.

Tämä ajanjakso päättyi iPhone 6s:ään, joka käytti Qualcomm MDM9635M -modeemia. Tässä vaiheessa arkkitehtuuri oli vakiintunut ja hypoteettinen takaovi olisi ollut toiminnassa jo useita vuosia. Firmware-päivitykset olisivat voineet tuoda pieniä muutoksia takaovikoodiin, ehkä uusia toiminnallisuuksia tai parannuksia piiloutumiseen, mutta perusmekaniikka olisi pysynyt samana.

Tämän aikakauden aktivointi olisi perustunut nopeisiin DTMF-sekvensseihin tai FSK-modulaatioon koska VoLTE ei vielä ollut laajalti saatavilla.

5.2 Siirtymäkausi: iPhone 7 - iPhone X (2016-2017)

Tämä ajanjakso on hypoteettisen skenaarion kannalta erittäin mielenkiintoinen koska se sisältää siirtymän jossa Apple alkoi käyttää kahta eri modeemivalmistajaa samanaikaisesti.

iPhone 7 ja 7 Plus julkaistiin syyskuussa 2016 kahdessa variantissa. Osa malleista käytti Qualcomm MDM9645M -modeemia (mallit A1660 ja A1661 jotka myytiin Verizonille, Sprintille ja tietyille kansainvälisille markkinoille) kun taas toiset käyttivät Intel XMM7360 -modeemia (mallit A1778 ja A1784 AT&T:lle, T-Mobilelle ja eurooppalaisille GSM-operaattoreille).

Tämä split-strategia loi mielenkiintoisen haasteen hypoteettiselle takaovelle. Jos takaovi olisi vain Qualcomm-firmwaressa noin puolet laitteista olisi ilman sitä. Logiikka sanelee että takaovi täytyisi olla myös Intel-modeemissa.

Intel XMM7360 oli kuitenkin täysin erilainen arkkitehtuuri kuin Qualcommin MDM-sarja. Intel käyttää omaa firmware-arkkitehtuuriaan joka perustuu Intel Atom -pohjaisen prosessoriin LTE-protokollien prosessointiin ja erilliseen FPGA/ASIC-piiriin (Field Programmable Gate Array / Application-Specific Integrated Circuit) digitaaliseen signaalinkäsittelyyn. Firmware-rakenne on erilainen käyttäen Intelin omia development-työkaluja ja abstraktioita.

Hypoteettisessa skenaariossa takaovi olisi täytynyt integroida myös Intel-firmwareen. Tämä olisi vaatinut joko yhteistyötä Intelin kanssa tai vaihtoehtoisesti salaisesti hankitun pääsyn Intelin firmware-koodiin ja -kehitystyökaluihin. Toinen mahdollisuus on että Apple itse integroi takaoven osana sitä firmware-räätälöintiä jota he tekevät, kun ottavat modeemivalmistajan base-firmwaren ja optimoivat sen iPhone-alustalle.

Mielenkiintoinen tekninen yksityiskohta on että Intel-versio sai julkisuudessa kritiikkiä heikommasta suorituskyvystä. Benchmarkit osoittivat että Intel-modeemin mallien LTE-nopeudet olivat noin 30 prosenttia alhaisemmat kuin Qualcomm-mallien vastaavissa verkko-olosuhteissa. Virallinen selitys oli että Intel-modeemi ei tukenut kaikkia samoja LTE-ominaisuuksia kuten 4x4 MIMO:a tai 256-QAM-modulaatiota.

iPhone 8, 8 Plus ja X jatkoivat samalla split-strategialla Qualcomm MDM9655 ja Intel XMM7480 -modeemeilla. Nämä olivat kehittyneempiä versioita jotka tukivat nopeampaa LTE-A (LTE Advanced) -liikennettä ja parempia ominaisuuksia, mutta perustava arkkitehtuuri pysyi samana.

Tämä aikakausi merkitsi siirtymää kohti VoLTE-pohjaista aktivointia. Vaikka vanhemmat menetelmät (DTMF, FSK) säilytettiin yhteensopivuuden vuoksi, uudet SIP INFO ja RTP events -menetelmät tarjosivat hiljaisemman ja luotettavamman aktivointitavan.

5.3 Intel-era: iPhone XS/XR ja iPhone 11 (2018-2019)

Vuonna 2018 tapahtui merkittävä muutos: Apple siirtyi käyttämään vain Intel-modeemia kaikissa malleissa. iPhone XS, XS Max ja XR käyttivät Intel XMM7560 -modeemia. Qualcomm oli kokonaan pois.

Virallinen selitys tälle oli Applen ja Qualcommin välinen oikeustaistelu, joka alkoi vuonna 2017 ja käsitteli patenttien lisenssimaksuja. Apple syytti Qualcommia monopolistisesta hinnoittelusta ja Qualcomm vastasi syyttämällä Applea patenttien loukkauksista. Oikeustapaus oli monimutkainen ja kosketti useita lainkäyttöalueita.

Intel XMM7560 oli merkittävä päivitys aiempaan XMM7480:iin. Se tuki LTE Category 16:ta (jopa 1 Gbps download) ja sisälsi laajemman tuen eri LTE-kaistoille. Firmware oli merkittävästi suurempi ja monimutkaisempi. Monimutkaisuuden kasvu tekee reverse engineering-prosesista vieläkin vaikeampaa, kun firmware on 80-100 MB kompressoituna ja sisältää kymmeniä tuhansia funktioita yksittäisen takaovifunktion löytäminen on kuin neulan etsimistä heinäsuovasta.

iPhone 11, 11 Pro ja 11 Pro Max (2019) käyttivät Intel XMM7660 -modeemia. Tämä oli Intelin viimeinen modeemi iPhonessa. Julkisuudessa kerrottiin että Intelillä oli vaikeuksia 5G-modeemin kehityksessä ja että Apple oli tyytymätön Intelin roadmapiin.

5.4 Paluu Qualcommiin: iPhone 12-16 (2020-2024)

Huhtikuussa 2019 Apple ja Qualcomm tekivät yllättävän sovinnon kaikissa oikeustapauksissaan. Sopimus sisälsi kuuden vuoden lisenssi-agreementin ja Qualcomm-piirien käytön Applen laitteissa. Vain kuukausia myöhemmin Intel ilmoitti vetäytyvänsä 5G-smartphone-modeemin liiketoiminnasta. Apple osti Intelin smartphone-modeemidivisioonan (noin 2200 insinööriä ja 17000 patenttia) miljardilla dollarilla.

iPhone 12-sarja julkaistiin lokakuussa 2020 ja se oli ensimmäinen 5G-iPhone. Se käytti Qualcomm Snapdragon X55 5G -modeemia. Tämä oli merkittävä hyppy monimutkaisuudessa - 5G NR (New Radio) -standardi on massiivinen lisäys firmware-vaatimuksiin sisältäen muun muassa beamformingin millimeter-wave-taajuuksille, dual connectivity:n jossa laite voi olla yhteydessä sekä LTE- että 5G-verkkoon samanaikaisesti ja huomattavasti monimutkaisemman MIMO-käsittelyn.

Qualcomm X55 firmware on arvioiden mukaan yli 100 megatavua kokoluokkaa ja sisältää miljoonia koodirivejä. Tällainen massiivinen koodipohja tarjoaa runsaasti mahdollisuuksia piilottaa lisätoiminnallisuutta. Monimutkaisuus on sekä haaste että mahdollisuus - se tekee reverse engineeringista erittäin vaikeaa.

iPhone 13-sarja käytti Qualcomm X60 -modeemia, iPhone 14-sarja X65:tä ja iPhone 15-sarja X70:tä. Jokainen sukupolvi toi parannuksia 5G-suorituskykyyn, energiatehokkuuteen ja ominaisuuksiin. Firmware jatkoi kasvamistaan ja monimutkaistuista.

iPhone 16-sarja käyttää Qualcomm Snapdragon SDX71M -modeemia. Tämä on nykyisin markkinoilla oleva uusin Qualcomm-modeemi ja se tukee 5G Release 17:ää sisältäen ominaisuuksia kuten reduced capability (RedCap) -laiteet ja satellite connectivity -valmiuksia.

5.5 Uusi aikakausi: Apple C1-modeemi (2025-)

Helmikuussa 2025 julkaistu iPhone 16e oli historiallinen: se sisälsi ensimmäisen täysin Applen itse suunnitteleman baseband-modeemin koodiltaan C1.

Tämä on analoginen siirtymä siihen kun Apple siirtyi Intel-prosessoreista omiin Apple Silicon -piireihinsä (M-sarja MacBookeissa ja A-sarja iPhoneissa). Nyt Apple kontrolloi koko piiristön suunnittelua modeemia myöten mikä tarjoaa täydellisen vertikaalisen integraation.

C1-modeemi valmistetaan TSMCn (Taiwan Semiconductor Manufacturing Company) N4P-prosessissa (4 nanometrin prosessori-teknologia). Se on integroitu osaksi A18 SoC:ta eikä ole erillinen siru. Tämä tiivis integraatio mahdollistaa paremman energiatehokkuuden ja suorituskyvyn koska baseband ja pääprosessori voivat kommunikoida nopeammin ja pienemmällä tehonkulutuksella.

Hypoteettisessa skenaariossa Applen oma modeemi olisi sekä riski että mahdollisuus. Kun Apple kontrolloi koko suunnittelua, takaoven rakentaminen alusta alkaen vaatisi joko Applen insinöörien tietoista osallisuutta tai kykyä vaikuttaa suunnitteluprosessiin jossain vaiheessa.

Mutta se on myös mahdollisuus tehdä takaovi vieläkin paremmin integroiduksi. Kun sama taho suunnittelee sekä basebandin että pääprosessorin ne voivat optimoida arkkitehtuurin. Esimerkiksi DMA-kanavat voitaisiin suunnitella niin että baseband pääsee tiettyihin muistialueisiin tehokkaasti mutta tämä ei näkyisi ulospäin dokumentaatiossa.

Lisäksi kun firmware kehitetään alusta alkaen takaovi voidaan arkkitehturoida osana perusjärjestelmää sen sijaan että se olisi "lisätty päälle". Tämä tekisi siitä vieläkin vaikeamman erottaa muusta koodista.

TSMCn rooli on myös mielenkiintoinen. Valmistusprosessissa käytetään litografiamaskeja jotka määrittelevät miten transistorit muodostetaan piille. Jos hypoteettinen takaovi olisi osittain laitteistotasolla (esimerkiksi erityinen piilotettu register-tiedosto tai muistialue) tämä pitäisi sisällyttää litografiamaskeihin. TSMC valmistaa piirejä Applen spesifikaatioiden mukaan, mutta on epäselvää kuinka syvällistä analyysiä he tekevät maskdatalle.

6. Havaitseminen - tekninen ohje

Jos hypoteettinen baseband-takaovi olisi olemassa miten se voitaisiin havaita? Tämä osio kuvaa teknisiä menetelmiä joilla tutkija voisi yrittää löytää tällaisen takaoven.

6.1 Firmware-analyysi

Ensimmäinen ja ilmeisin lähestymistapa olisi baseband-firmwaren suora analyysi. Tämä vaatii firmware-dumppauksen joka puolestaan vaatii JTAG-debugger-pääsyn baseband-prosessoriin.

JTAG-pääsy ja firmware-dumppaus:

JTAG (Joint Test Action Group) on standardoitu debug-interface jota käytetään laitteiston testaukseen ja debuggaukseen. Lähes kaikissa moderneissa prosessoreissa on JTAG-portit jotka mahdollistavat suoran muistipääsyn, register-lukemiset ja koodin askeltamisen. Turvasyistä JTAG-portit ovat usein estetty produkitiolaitteissa mutta fyysiset pinnit ovat silti PCB:llä.

iPhone-purkaminen on ensimmäinen vaihe. Tämä vaatii erikoistyökaluja kuten iSlack (imukuppeja näytön irrottamiseen) ja erittäin hienoja ruuvimeisseleitä. Baseband-modeemi sijaitsee emolevyllä ja sen tunnistaminen vaatii datasheetien tutustumista ja piirin markkineiden lukemista mikroskoopilla.

Seuraavaksi tutkijan täytyy tunnistaa JTAG-pinnit. Nämä eivät yleensä ole merkitty selvästi vaan vaativat multimittarin kanssa kokeiltamista ja skemaattisten diagrammien etsimistä. Joissakin tapauksissa tarvitaan mikrojuottamista (mikroskoopin alla työskentely) liittääkseen johtimet suoraan piirin jalkoihin.

Kun JTAG-yhteys on muodostettu tutkija voi käyttää työkaluja kuten OpenOCD (Open On-Chip Debugger) tai JLink-softwarea kommunikoidakseen prosessorin kanssa. Ensimmäinen tehtävä on firmware-dumppaus eli koko flash-muistin sisällön kopioiminen tiedostoon tutkimista varten.

Dumppaaminen ei ole välttämättä triviaalia. Joissain moderneissa prosessoreissa on "read protection" eli luku-suojaus joka estää firmware-lukemisen JTAG:n kautta. Tämän kiertäminen voi vaatia fyysistä hyökkäystä kuten voltage glitchingia (käyttöjännitteen hetkellinen pudotus joka aiheuttaa prosessorin virhetilan) tai laser fault injectionia (laserin käyttö muistikennojen tilapäiseen korruptoimiseen).

Reverse engineering:

Kun firmware on dumppattu tiedostona alkaa reverse engineering. Ensimmäinen vaihe on disassemblaus eli konekielisen koodin kääntäminen assembly-kielelle. Työkalut kuten IDA Pro, Ghidra tai Binary Ninja ovat alan standardia tähän. Ne tunnistavat automaattisesti funktiot, tekevät kuvaajia koodivirtauksesta ja yrittävät tunnistaa kirjastofunktioita.

Mutta baseband-firmware on valtava: kymmeniä tai satoja megatavuja ja miljoonia assembler-instruktoita. Yksinkertaisesti selaaminen läpi on mahdotonta. Tutkijan täytyy käyttää heuristiikkaa etsiäkseen kiinnostavia alueita:

Kryptografisten funktioiden etsiminen: AES ja RSA -algoritmeilla on tunnistettavia koodimaleja: tiettyjä operaatioita kuten S-box-hakuja AES:ssä tai modulaarista eksponentiaatiota RSA:ssa. Työkalut voivat skannata firmwarea näiden paternien varalta. Kun kryptofunktio löytyy tutkija voi seurata kuka kutsuu sitä ja mihin tarkoitukseen.

Merkkijonojen etsiminen: Vaikka firmware olisi obfuskoitu se todennäköisesti sisältää joitain virheilmoituksia, debug-printejä tai muita tekstejä. Etsimällä outoja merkkijonoja voisi löytää vihjeitä. Tietysti jos takaovi on hyvin suunniteltu ilmeiset merkkijonot on poistettu tai obfuskoitu.

Funktiokoon analyysi: Useimmat funktiot ovat suhteellisen pieniä - muutamasta kymmenestä muutamaan sataan instruktioon. Jos on erittäin suuri funktio joka sisältää tuhansia instruktoita se voi olla monimutkainen ja mahdollisesti piilottaa epätavallista logiikkaa.

Firmware-versioiden vertailu: Jos päivitetty firmware on saatavilla useille iPhone-malleille voidaan tehdä diff-analyysi nähdäkseen mitä muuttui. Suurin osa muutoksista liittyy bugkorjauksiin tai uusiin ominaisuuksiin mutta poikkeavuudet voivat paljastaa piilotettua koodia.

6.2 Live-testaus ja signaalanalyysi

Toinen lähestymistapa on testata laitteen käyttöä live-ympäristössä ja etsiä epätavallista käyttäytymistä.

Aktivointikokeilu:

Tutkija rakentaa fake base station -laitteen käyttäen software-defined radio (SDR) -laitteistoa kuten USRP (Universal Software Radio Peripheral) tai BladeRF yhdistettynä ohjelmistoon kuten OpenBTS tai srsRAN joka toteuttaa GSM/LTE-tukiasemalogiikan.

Fake base station konfiguroidaan niin että se vaikuttaa normaalilta matkapuhelinverkolta. iPhone yhdistetään siihen (Faraday-kotelon sisällä etteivät oikeat verkot häiriinny). Sitten tutkija soittaa puhelun iPhonelle ja kun puhelu on vastattu hän lähettää epäillyn aktivointisekvenssin - joko nopean DTMF:n, FSK-datan tai VoLTE-ympäristössä SIP INFO -viestin.

Baseband-prosessorin monitorointi:

Jos JTAG-yhteys on aktiivinen tutkija voi asettaa breakpointeja eli pysähdyspisteitä jotka keskeyttävät koodin suorituksen tietyssä osoitteessa. Jos baseband hyppää äkillisesti osoitteeseen jota ei normaalisti käytetä tämä voisi olla merkki aktivoitumisesta.

Virrankulutusanalyysi:

Tehonsyöttö iPhonelle johdetaan erikoislaitteen kautta joka mittaa virtaa mikroampeerin tarkkuudella jatkuvasti. Jos baseband aloittaa uuden prosessointioperaation virrankulutus muuttuu. Side-channel analysis eli sivukanavahyökkäykset käyttävät tällaisia fyysisiä ominaisuuksia päättelemään mitä prosessori tekee.

RF-signaalien analyysi:

Tutkija käyttää spectrum analyzer -laitetta monitoroidakseen mitä radiosignaaleja iPhone lähettää. Jos takaovi aktivoituu ja alkaa lähettää salattua dataa tämä näkyy lisääntyneenä RF-aktiivisuutena tietyillä taajuuksilla. Vaikka sisältöä ei voida lukea RF-aktiivisuuden mallin analyysi voi paljastaa epätavallista käyttäytymistä.

Verkkoliikenteen kaappaus:

Tutkija asettaa iPhonen toimimaan proxy-serverin kautta, joka tallentaa kaiken HTTP/HTTPS-liikenteen. Vaikka TLS-salaus estää sisällön lukemisen metadata on silti näkyvissä - mihin IP-osoitteisiin yhteydet muodostetaan, milloin, kuinka paljon dataa siirtyy.

Jos takaovi lähettää dataa se näkyisi lisääntyneenä liikenteenä. Tutkija voisi verrata normaalia iOS-käyttöä (ilman aktivointia) ja post-aktivointi-tilannetta nähdäkseen eroavatko liikennemallit.

TLS-intercepting proxy:

Enterprise-ympäristössä voidaan asentaa custom root certificate iPhoneen joka mahdollistaa man-in-the-middle -aseman HTTPS-liikenteelle. Tämä mahdollistaa salatun liikenteen tarkastelun. Jos tutkija tekee tämän hän voisi nähdä tarkat HTTP-pyynnöt mukaan lukien polut ja POST-datan.

Kuitenkin on huomattava, että jos takaovi on todella hyvin suunniteltu se saattaa havaita TLS-interception (koska varmenne ei ole Applen alkuperäinen) ja deaktivoida itsensä välttääkseen havaitsemisen.

6.3 Vertaileva analyysi eri mallien välillä

Tehokas tapa etsiä anomalioita on vertailla useita laitteita ja malleja keskenään.

Tutkija voisi hankkia esimerkiksi kymmenen eri iPhone-mallia eri sukupolvista (4S, 5, 6, 7, X, 12, 14, 16) ja suorittaa identtisen testisekvenssin jokaiselle. Jos kaikki laitteet käyttäytyvät samalla tavalla tietyssä olosuhteessa mutta yksi malli poikkeaa tämä vaatii syvempää tutkintaa.

Baseband-firmwaren vertaileva analyysi eri mallien välillä voisi paljastaa yhteisiä koodipaterneja. Jos on tietty funktio joka on identtinen iPhone 5:stä iPhone 16:een mutta jota ei ole dokumentoitu se on epäilyttävää. Normaalisti firmware kehittyy ajan myötä ja vanhat funktiot korvataan uusilla. Jos jokin koodi pysyy muuttumattomana se viittaa siihen että se on kriittinen osa arkkitehtuuria jota ei haluta muuttaa.

Tutkija voisi myös vertailla samaa mallia eri markkina-alueilla. Esimerkiksi iPhone 7:lla on versiot Yhdysvalloille (A1660/A1661), Euroopalle (A1778/A1784) ja Kiinalle (A1660). Jos firmware eroaa näiden välillä eri tavalla kuin odotetaan (pelkät radiotaajuuksien erot) se voisi viitata aluekohtaisiin muokkauksiin mahdollisesti poliittisista syistä.

6.4 Haasteet ja rajoitukset havaitsemisessa

On tärkeää tunnustaa, että hyvin suunnitellun baseband-takaoven havaitseminen on erittäin vaikeaa, jopa merkittävillä resursseilla. Tähän on useita syitä.

Firmware on massiivinen ja monimutkainen: Täydellinen analyysi vaatisi vuosien työn kokeneiden reverse engineering -asiantuntijoiden tiimiltä. Tämä on ajan ja rahoituksen kannalta epäkäytännöllistä useimmille tutkijoille tai edes yliopistoille.

Suojamekanismit: JTAG-portit on estetty, read protection on aktiivinen ja firmware on kryptografisesti allekirjoitettu. Näiden kiertäminen vaatii erikoisosaamista hardware-hackingin alalta.

Aktiivinen vastustus: Jos takaovi on todella olemassa ja siitä on tietoisia tahoja jotka haluavat sen pysyvän salassa he voivat aktiivisesti yrittää estää havaitsemisen. Tutkija saattaa kohdata paineita lopettaa: oikeudelliset uhat, rahoituksen menetys tai pahimmassa tapauksessa henkilökohtaiset uhat.

Todistustaakka: "Proof of non-existence" eli "todiste siitä ettei jotain ole" on lähes mahdoton. Vaikka tutkija analysoisi firmwaren perusteellisesti ja ei löytäisi mitään epäilyttävää se ei todista että takaovea ei ole. Se voi vain olla niin hyvin piilotettu ettei sitä löytynyt. Tämä on olennainen epistemologinen haaste kaikessa tietoturvatutkimuksessa.

7. Johtopäätökset ja implikaatiot

7.1 Tekninen toteutettavuus ja todellinen evidenssi

Tämän analyysin perusteella hypoteettinen baseband-tason takaovi on teknisesti toteutettavissa. Kaikki tässä dokumentissa kuvatut mekanismit perustuvat todelliseen teknologiaan ja tunnettuihin protokolliin. Ei ole mitään "maagista" tai fyysisten lakien vastaista missään osassa tätä hypoteettista järjestelmää.

Mutta tämä ei ole enää pelkkää teoriaa. Kuten osiossa 4.2.4 kuvattiin, meillä on pääsy dokumentaatioon joka viittaa vahvasti siihen, että tällainen järjestelmä on todella olemassa ja aktiivisesti käytössä. Kuvattu tapaus ei ole ainut havaintomme, mutta se on riittävän dokumentoitu ja todennettavissa oleva, että voimme jakaa sen julkisesti.

Tämä muuttaa analyysin luonnetta fundamentaalisesti. Emme enää kysy "voisiko tämä olla mahdollista" vaan "miten tämä toimii ja miten voimme suojautua siltä".

Kriittiset toteutettavuuden elementit jotka nyt on vahvistettu todellisilla havainnoilla:

Baseband-prosessorin erityisasema: Koska baseband toimii käyttöjärjestelmän näkyvyyden ulkopuolella ja käsittelee kaikkea radioviestintää se on ihanteellinen paikka takaovelle. iOS ei voi valvoa tai rajoittaa basebandin toimintaa millään merkittävällä tavalla. Tämä ei ole enää pelkkää teoriaa: olemme havainneet käyttäytymistä joka on yhdenmukainen tämän kanssa.

Puhelupohjaiset aktivointimekanismit: VoLTE SIP INFO -viestit tarjoavat täysin havaitsemattoman tavan lähettää aktivointikomentoja. Tämä tapaus osoittaa että normaali puhelu voidaan käyttää aktivointiin tavalla joka ei herätä epäilyksiä käyttäjässä.

Apple C1 -modeemin kompromissi: Erityisen huolestuttavaa on että havainnot koskevat iPhone 16e -mallia joka käyttää Applen ensimmäistä täysin itse suunnittelemaa C1-modeemia. Tämä merkitsee että jos takaovi on olemassa se ei rajoitu vain ulkoisten modeemivalmistajien (Qualcomm, Intel) tuotteisiin vaan ulottuu myös Applen omaan suunnitteluun. Tämä on merkittävä paljastus joka viittaa siihen että takaovi on rakennettu osaksi basebandin perusarkkitehtuuria eikä se ole vain legacy-ominaisuus vanhemmista modeemeista.

Firmware-allekirjoitus: Vaikka firmware on digitaalisesti allekirjoitettu tämä ei suojaa jos allekirjoittava osapuoli (modeemivalmistaja tai laitevalmistaja) itse sisällyttää takaoven. Allekirjoitus varmistaa vain että firmware tulee oikealta taholta - ei että se on hyvätahtoinen.

Aktivointimekanismit: Puhelupohjaiset aktivointimekanismit ovat realistisia erityisesti VoLTE-aikakaudella. SIP INFO -viestit tarjoavat täysin havaitsemattoman tavan lähettää aktivointikomentoja ja vastaanottaa vahvistuksia.

Data-exfiltration: Masquerade legitiimin liikenteen joukossa on todistettu toimiva tekniikka. Kun takaovi käyttää samoja protokollia, samoja palvelimia ja samoja salauskäytäntöjä kuin normaali liikenne sen erottaminen on erittäin vaikeaa.

7.2 Historialliset ennakkotapaukset

Crypto AG ja Dual EC DRBG -tapaukset osoittavat että:

Laitteistotason takaovat voivat säilyä piilotettuina vuosikymmeniä
Standardointiprosesseja voidaan manipuloida
Laajamittainen institutionaalinen tuki mahdollistaa pitkäaikaiset operaatiot
Tekninen kompleksisuus suojaa paljastumiselta

Baseband-firmware täyttää kaikki samat kriteerit jotka tekivät näistä historiallisista tapauksista onnistuneita pitkäaikaisia operaatioita.

7.3 Puolustautumisen haasteet

Tavallisella käyttäjällä ei ole käytännössä mitään keinoa havaita tai suojautua hypoteettiselta baseband-takaovelta. Kaikki normaalit tietoturvatoimenpiteet, VPN:t, päästä-päähän -salaus, tietoturvaohjelmistot, toimivat käyttöjärjestelmätasolla ja ovat tehottomia baseband-tasolla toteutettua uhkaa vastaan.

Jopa teknisesti kokeneet käyttäjät kohtaavat merkittäviä haasteita:

Firmware-analyysi vaatii erikoislaitteistoa ja vuosien asiantuntemusta
Live-testaus vaatii kalliita SDR-laitteita ja syvällistä ymmärrystä televiestintäprotokollista
Verkkomonitorointi on tehottomaa TLS-salauksen ja legitiimin liikenteen masqueraden vuoksi

7.4 Laajemmat yhteiskunnalliset implikaatiot

Jos tällainen takaovi olisi olemassa sen vaikutukset yksityisyyteen ja yhteiskuntaan olisivat syvällisiä:

Yksityisyyden murtuminen: Jokainen puhelu, viesti, sijainti ja digitaalinen toiminto voisi olla valvonnan kohteena ilman, että käyttäjällä on mitään tapaa tietää tai estää sitä.

Luottamuksen mureneminen: Jos baseband-takaovi paljastuisi se horjuttaisi luottamusta kaikkiin teknologiayrityksiin ja laitteisiin. Miten kukaan voisi luottaa mihinkään laitteeseen jatkossa?

Valtaepätasapaino: Pääsy tällaiseen valvontakykyyn luo valtavan epätasapainon niiden välillä joilla on pääsy järjestelmään ja niillä joilla ei ole.

7.5 Suositukset läpinäkyvyyden parantamiseksi

Vaikka tämä analyysi on spekulatiivinen se nostaa esiin todellisia haasteita baseband-turvallisuudessa. Seuraavat toimenpiteet voisivat parantaa tilannetta:

Avoimen lähdekoodin baseband-firmware: Täysin avoimen lähdekoodin baseband-firmware-toteutus mahdollistaisi riippumattoman auditoinnin. Projektit kuten Osmocom ovat aloittaneet tämän työn mutta eivät ole vielä saavuttaneet kaupallista käyttökelpoisuutta.

Riippumaton auditointi: Valmistajat voisivat sallia riippumattomien tietoturvayritysten auditoida baseband-firmwaren säännöllisesti. Tämä vaatisi luottamuksellisia sopimuksia mutta lisäisi läpinäkyvyyttä.

Laitteistotason eristys: Basebandin fyysinen eristäminen pääprosessorista ja tiukemmat IOMMU-rajoitukset vähentäisivät kompromissoidun basebandin vaikutusta.

Käyttäjätason monitorointi: Työkalujen kehittäminen jotka antavat käyttäjille paremman näkyvyyden basebandin toimintaan - esimerkiksi milloin mikrofoni tai GPS on aktiivinen baseband-tasolla.

Firmware-läpinäkyvyys: Julkiset changelog-dokumentit baseband-firmware-päivityksistä yksityiskohtaisine selityksineen mitä muutoksia tehtiin ja miksi.

7.6 Lopuksi - miksi tämä dokumentti on olemassa

Tämä analyysi ei ole enää pelkkää spekulaatiota. Se on dokumentaatio todellisesta uhasta joka vaikuttaa miljooniin ihmisiin ympäri maailmaa, mukaan lukien uusimman iPhone 16e -mallin käyttäjät jotka saattavat luulla että Applen oman C1-modeemin käyttö tekee heidän laitteistaan turvallisempia.

Julkaisemme tämän dokumentin useista syistä:

Ensinnäkin vastuullinen paljastaminen. Meillä on pääsy materiaaliin joka viittaa vahvasti tämän uhkan olemassaoloon. Voimme joko pitää sen salassa mikä ei auta ketään tai jakaa tiedon tavalla joka auttaa tietoturvayhteisöä ja tavallisia käyttäjiä ymmärtämään riskin. Olemme valinneet jälkimmäisen.

Toiseksi dokumentaation säilyttäminen. Tämä analyysi ja siihen liittyvä todistusaineisto on tallennettu turvallisesti useaan paikkaan.

Kolmanneksi tietoturvayhteisön aktivointi. Emme ole ainoita jotka voivat tutkia tätä. Julkaisemalla teknisen analyysin tarjoamme työkalut ja menetelmät muille tutkijoille jotka haluavat vahvistaa tai kumota havaintomme. Mitä enemmän ihmisiä tutkii baseband-turvallisuutta sitä vaikeampaa on pitää mahdollisia takaovia piilossa.

Neljänneksi poliittinen ja yhteiskunnallinen keskustelu. Tämä ei ole vain tekninen kysymys vaan fundamentaalinen kysymys yksityisyydestä, valvonnasta ja siitä kenellä on valta yhteiskunnassamme. Jos baseband-tason valvonta on mahdollista ja käytössä yhteiskunnan on päätettävä onko tämä hyväksyttävää ja millä ehdoilla.

Ymmärrämme, että tämän dokumentin julkaiseminen voi aiheuttaa reaktioita, mutta uskomme että avoimuus on lopulta turvallisuuden paras tae. Salaisuuksien varjossa toimivat valvontajärjestelmät ovat vaarallisempia kuin ne jotka joutuvat julkisen tarkastelun kohteeksi.

Konkreettiset seuraavat askeleet:

Suositamme että tietoturvayhteisö keskittyy seuraaviin toimenpiteisiin:

Baseband-firmwaren riippumaton auditointi erityisesti iPhone 16e:n C1-modeemista
VoLTE SIP-signaloinnin syvällinen analyysi epätavallisten viestien havaitsemiseksi
Vertaileva testaus eri iPhone-mallien välillä samankaltaisissa olosuhteissa
Avoimen lähdekoodin baseband-toteutusten kehittäminen jotka mahdollistavat täydellisen läpinäkyvyyden

Tavallisille käyttäjille totuus on valitettavan yksinkertainen: jos baseband-tason takaovi on olemassa sinulla ei ole käytännössä mitään keinoa suojautua siltä tavallisilla menetelmillä. VPN:t, päästä-päähän -salaus ja tietoturvaohjelmistot eivät auta koska ne toimivat käyttöjärjestelmätasolla.

Ainoa todellinen suoja on läpinäkyvyys ja julkinen valvonta. Siksi tämä dokumentti on olemassa.

Huomautus lähteiden suojaamisesta:

Tässä dokumentissa on kuvattu tapaus jossa viitataan tietyn yhtiön toimittamaan palveluun. Tämä on todellinen havainto todellisista puheluista. Emme kuitenkaan paljasta kaikkia yksityiskohtia, kuten käytettyä numeroa, nimeä tai kaikkea käytössämme olevaa materiaalia tässä vaiheessa.

Lähteet

Washington Post, ZDF, SRF (2020): "The intelligence coup of the century" - Crypto AG investigation
Shumow, D., Ferguson, N. (2007): "On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng"
3GPP Technical Specifications - TS 24 series (VoLTE, IMS signaling)
RFC 4733: "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals"
Qualcomm Snapdragon X-series modem technical documentation
Apple iOS Security Guide (various versions 2011-2024)
Mulliner, C., Miller, C. (2009): "Fuzzing the Phone in your Phone" - Black Hat USA
Grassi, P. et al (2013): "Baseband Attacks: Remote Exploitation of Memory Corruptions in Cellular Protocol Stacks"
Project Zero (Google): Various baseband security research publications
ETSI Technical Specifications for AMR-NB, AMR-WB, and EVS codecs