ATAK-lisäosa ei ole kuluttajasovellus. Se toimii laitteessa, joka viedään kiistanalaiselle maastoon, jota operaattorit käyttävät tulituksen alla, ja jonka viholliset saattavat mahdollisesti kaapata — viholliset, jotka ymmärtävät täsmälleen, miltä TAK-ohjelmisto näyttää ja miksi sen käänteinen suunnittelu on arvokasta. Taktisen Android-lisäosan turvallisuusaseman on oltava suunniteltu tämän todellisuuden ympärille — ei vähittäispankkisovelluksen uhkamallin ympärille.
Tämä artikkeli kattaa täydellisen vahvistuspinon ATAK-lisäosien kehittämiseen: uhkamallista hämärtämisen, peukaloinnin estämisen, turvallisen tallennuksen, varmenteen kiinnityksen, verkkoturvallisuuden, turvallisen poistamisen ja build-putkilinjan eheyden kautta. Jokainen osio selittää, mitä ohjausmekanismi suojaa, mitä se ei suojaa, ja TAK-ekosysteemissä tärkeät toteutusyksityiskohdat.
Uhkamalli: mitä puolustat
Neljä uhkaskenaariota tulisi ohjata jokaista TAK-lisäosan turvallisuuspäätöstä: kaapattu laite, pahantahtoinen sisäpiiriläinen, verkkopohjainen hyökkäys ja toimitusketjun vaarantuminen. Kaapattu kestävä Android-laite antaa vastustajalle rajoittamattoman fyysisen ajan APK:n poimimiseen, salatun tallennuksen analysointiin offline-tilassa ja laitteen kloonaamiseen laboratorioon. Sisäpiiriuhkat ohittavat useimmat tekniset valvontatoimenpiteet — tallennettujen tietojen minimointi ja MDM-auditointipolut ovat ensisijaiset vastatoimenpiteet. Verkkopohjaiset hyökkäykset ratkaistaan varmenteen kiinnittämisellä ja TLS-pakottamisella. Toimitusketjun vaarantuminen vaatii toistettavia buildejä, SBOM-generointia ja binäärin allekirjoittamista.
Koodin hämärtäminen: ProGuard/R8-konfiguraatio
Androidin R8-kääntäjä suorittaa pienentämisen, hämärtämisen ja optimoinnin. Kaikkien kolmen tulisi olla käytössä julkaisubuildeissa. Keep-sääntöjen on säilytettävä AbstractPlugin-aliluokka, XML-viittaavat luokat ja Parcelable/Serializable-toteutukset. Merkkijonoliteraalit — palvelimen isäntänimet, API-polut — selviävät R8:sta muuttumattomina ja ne on salattava erikseen käyttämällä kirjastoa kuten StringFog, jolloin salauksen purkuavain johdetaan Android Keystoresta. Hämärtäminen on viivästysmekanismi, ei tietoturvaraja.
Peukaloinnin estäminen: allekirjoituksen varmennus, root-tunnistus, emulaattorin tunnistus
Alustuksen yhteydessä APK-allekirjoitussertifikaatin hash varmennetaan koottuun odotettuun arvoon — eroavaisuus osoittaa uudelleenpakkauksen ja sen tulisi laukaista pyyhintä ja käynnistyksen kieltäytyminen. Käytä GET_SIGNING_CERTIFICATES Android 9:ssä+ v3-avainrotaation käsittelyyn. Root-tunnistus yhdistää su-binääritar kastukset, tunnettujen root-sovellusten läsnäolon, /system-kirjoitettavuuden ja Play Integrity API:n — vain MEETS_STRONG_INTEGRITY on hyväksyttävä arkaluonteisille tiedoille.
Turvallinen tallennus: Android Keystore, EncryptedSharedPreferences, SQLCipher
Luo kaikki kryptografiset avaimet Android Keystoressa laitteistotukemalla, käyttäjätodennuksen sidonnalla ja biometrisen invalidoinnilla. Käytä EncryptedSharedPreferences (Jetpack Security) tokeneille ja konfiguraatiolle. Käytä SQLCipheria (SQLite:n drop-in-korvaaja) paikallisille operatiivisille tietokannoille, jolloin salasana tulee Keystoresta. StrongBox-tuettu Keystore tarjoaa vahvimman TEE-takuun.
Varmenteen kiinnitys: OkHttp/TrustKit-toteutus ja pin-rotaatio
Lisää OkHttp CertificatePinner ensisijaisella julkisen avaimen hashilla ja vähintään yhdellä varapin-koodilla. Kiinnitä julkisen avaimen hashit (ei varmenteen hasheja) selviytyäksesi varmenteen uusimisesta ilman lisäosapäivityksiä. TrustKit lisää vikaraportoinnin aktiivisten MITM-yritysten havaitsemiseksi. Ylläpidä 30 päivän päällekkäisyysikkunaa pin-rotaation aikana, jotta kaikki käyttöönotetut asiakkaat voivat päivittää ennen vanhan pin-koodin vanhenemista.
Verkkoturvallisuus: TLS 1.3, varmenteen läpinäkyvyys, HPKP-otsikot
Pakota TLS 1.3 (TLS 1.2 -varasuunnitelma vain vanhoille TAK-palvelimille) OkHttp ConnectionSpec:in kautta. Aseta cleartextTrafficPermitted="false" verkkoturvallisuuskonfiguraatiossa. Ota varmenteen läpinäkyvyyden varmennus käyttöön. Käytä HPKP-vastausotsikkoja puolustuksen syvyyskerroksena muille kuin selaimen TAK-asiakkaille.
Tietojen minimointi ja turvallinen poistaminen
Säilytä paikallisesti vain se, mitä tarvitaan odotetun irrotetun toimintajakson aikana. Nollaa arkaluonteiset muistissa olevat tavutaulukot ennen viittauksen poistamista. Ennen arkaluonteisten tiedostojen poistamista ylikirjoita sisältö nollilla — File.delete() yksinään ei estä oikeuslääketieteellistä palautumista. Tee SQLCipher WAL -tarkistuspiste ennen ylikirjoitusta. Rekisteröi laitteet MDM:ään ja testaa etäpyyhintä käyttöönoton aikana.
Build-putkilinjan turvallisuus: toistettavat buildit, SBOM, binäärin allekirjoitus, todentaminen
Lukitse kaikki riippuvuudet gradle.lockfile:iin, poista build-aikaleimaukset ja kiinnitä työkaluketjun versio toistettaville buildeille. Generoi CycloneDX- tai SPDX-SBOM jokaisessa CI-buildissa nopeaa CVE-triaagia varten. Tallenna APK-allekirjoitusavain HSM:ään. Käytä APK Signature Scheme v3:a. Julkaise allekirjoitettu todentamisasiakirja, joka yhdistää APK:n SHA-256 sen lähdesitoumukseen ja SBOM:iin.