Sekuriteit
Hoe die kluis gebou is, en wat 'n deurbraak sou vind.
Laas opgedateer 21 September 2026 · AssuredAuth, deur CircleRoll LLC
Dit is die publieke beskrywing van hoe AssuredAuth die tweefaktor-geheime, wagwoorde en kaarte wat jy daarin hou, beskerm. Dit is geskryf sodat 'n sekuriteitsbewuste leser elke bewering teen die toepassing en teen die gepubliseerde toetsvektore (beskikbaar vir enige resensent op aanvraag by hello@assuredauth.com) kan nagaan. Dit sê wat waar is en niks meer nie: niks hier beweer dat dit onaanvalbaar is nie, en niks word in persentasies belowe nie.
Die kort weergawe: die kluis bestaan op een plek, jou foon. Elke waarde daarin word geïnkripteer met 'n sleutel wat die foon se sekuriteitshardeware hou en nie kan uitvoer nie. Ons gebruik geen kluisbediener nie, hou geen kopie en hou geen sleutel nie. 'n Rugsteunlêer verlaat die foon slegs nadat dit geïnkripteer is onder 'n wagwoordfrase wat nooit êrens gestoor word nie.
Rapporteer 'n probleem: hello@assuredauth.com. Sien "Rapportering van 'n swakpunt" aan die einde.
1. Wat is geïnkripteer, met wat
| Data | Op die foon | Sleutel |
|---|---|---|
| Twee-faktor geheime (TOTP/HOTP/Steam sade) | Op die foonSleutelhanger (iOS) / Android Keystore-gesteunde winkel | SleutelDie platform se hardeware-gebonde sleutel; die databasisry bevat slegs 'n verwysing (secretRef), nooit die saad nie. |
| Wagwoorde (die wagwoordwaarde, notas) | Op die foonVerseëlde ry: AES-256-GCM, 'n ewekansige 96-bis nonce per waarde | Sleutel'n Willekeurige 256-bis datasleutel, self toegedraai deur die hardewaresleutel in §2 |
| Kaarte (nommer, vervaldatum, naam op kaart, CVC) | Op die foonDieselfde seël as wagwoorde; die CVC is opsioneel en word slegs gestoor as jy dit invoer | SleutelDieselfde datasleutel |
| Metadata (diensname, gebruikersname, ikone, sorteervolgorde) | Op die foonDie toepassing se databasis (SwiftData / Room) | SleutelBeskerm deur die bedryfstelsel se lêerenkripsie; behandel as nie-geheim |
| Rugsteunlêer (.authbackup) | Op die foonWaar jy dit ook al plaas: Lêers, iCloud Drive, Google Drive appDataFolder, 'n deelblad | Sleutel'n Sleutel afgelei van jou wagwoordfrase (§3). Apple en Google ontvang die verseëlde lêer en niks anders nie. |
| Metgesel vir Watch / Wear | Op die foonDie horlosie se eie sleutelhanger / Geënkripteerde Gedeelde Voorkeure | SleutelDie horlosieplatform se sleutels; oorgedra oor die platform se gekoppelde toestelkanaal |
| Verkeer vir rekenaaruitbreidings (eenmalige kodes op aanvraag) | Op die foonNie gestoor nie; oorgedra as end-tot-end geënkripteerde koeverte | Sleutel'n X25519-sleutelpaar per paring, privaat sleutel in die Sleutelhanger / Sleutelstoor; die aflos sien slegs syferteks |
Diagnostiek het geen metode wat 'n geheim aanvaar nie. Geen analitiese gebeurtenis dra 'n kluisveld nie. Geen waarde van die kluis word ooit na 'n logboek geskryf nie, in enige bou.
2. Waar die sleutels woon, op elke platform
iOS. Die datasleutel word toegedraai deur 'n sleutel wat binne die Veilige Enklawe (kSecAttrTokenIDSecureEnclave) gegenereer word met toegangsbeheer .privateKeyUsage + .userPresence, accessibility …ThisDeviceOnly, in die toepassing se gedeelde Sleutelhanger-toegangsgroep sodat die AutoFill-uitbreiding dieselfde sleutel kan gebruik. Die privaat sleutel kan nie deur die toepassing, deur 'n rugsteun of deur 'n ontfouter uit die Enklawe gelees word nie; die Enklawe stem slegs in om dit te gebruik nadat die gebruiker teenwoordig is (Face ID, Touch ID of die toestel se wagwoord). ThisDeviceOnly beteken dat 'n iCloud- of iTunes-rugsteun van die foon nie die sleutel dra nie; 'n herstelde foon begin met 'n leë kluis en vra vir jou rugsteunlêer en wagwoordfrase. 'n Foon sonder 'n wagwoord kan nie 'n .userPresence-sleutel oopmaak nie (die Enclave weier om een te skep), en die simulator volg dieselfde pad volgens ontwerp (sy teenwoordigheidsaanwysing is 'n waarskuwing wat geen toets kan beantwoord nie): daar is die datasleutel 'n gewone toestel-alleenlik-sleutelhanger-item - steeds uit elke rugsteun, steeds onleesbaar terwyl die foon gesluit is, maar sonder 'n tweede aanwysing - en die Sekuriteitskerm sê presies dit en stel voor dat 'n wagwoord ingestel word.
Android. Die datasleutel word toegedraai deur 'n AndroidKeyStore AES-256-sleutel, gegenereer in StrongBox wanneer die toestel een het (andersins die TEE), met setUserAuthenticationRequired(true) en 'n 30-sekonde verifikasiegeldigheid nadat 'n biometriese of toestelbewys, setUnlockedDeviceRequired(true), en setInvalidatedByBiometricEnrollment(true) aangeskakel is. Daardie laaste vlag is eerlik eerder as lasdraend: Android pas dit slegs toe op sleutels wat 'n biometriese nommer by elke gebruik vereis, so op hierdie 30-sekonde sleutel met die toestelbewys toegelaat verander dit niks - wat 'n vreemdeling se vinger uithou, is dat die inskrywing van 'n mens die PIN benodig, en dat die verwydering van die skermslot die sleutel permanent ongeldig maak. Sleutelstoorsleutels is nie uitvoerbaar nie en word uitgesluit van Android se wolkrugsteun. 'n Domein wat 'n toepassing op sy eie aansigte benoem (webDomain) word slegs geglo van 'n bekende blaaier; van enige ander pakket moet dit ook een wees wat die stelsel vir daardie pakket geverifieer het (Digital Asset Links), aangesien enige toepassing enige domein kan opeis.
Wat dit beteken vir 'n gesteelde databasislêer. Die SQLite-lêer en die verseëlde rye is gekisfereerde teks. Die sleutel wat hulle oopmaak, is in sekuriteitshardeware op die foon waarvandaan die lêer gekom het en kan nie saam met die lêer gekopieer word nie. Daar is niks om vanlyn te raai nie: die datasleutel is lukraak, nie afgelei van enigiets wat 'n persoon gekies het nie.
3. Die rugsteunlêer
Rugsteun is die een ding wat die foon verlaat, so dit is die een plek waar 'n vanlyn aanval in beginsel moontlik is. Die ontwerp maak daardie aanval duur en gee dit so min as moontlik om mee te werk:
- Die wagwoordfrase is ten minste 12 karakters lank (die blad weier minder en wys 'n sterktebalk).
- Geen wagwoordfrase-wenk word enige plek gestoor, in die lêer of in die toepassing nie.
- 'n Vars, ewekansige 16-greep sout en 12-greep nonce vir elke lêer wat geskryf word.
- Die hele liggaam is AES-256-GCM, so 'n verkeerde wagwoordfrase of 'n beskadigde lêer word geweier en nooit in die vullisdrom ontsyfer nie.
- Die opskrif (formaat, weergawe, KDF-parameters, sout) word as bykomende geverifieerde data in die GCM-etiket gebind, sodat 'n lêer waarvan die werkfaktor afgeskaal is, nie oopmaak nie.
Die lêer is JSON en leesbaar in enige teksredigeerder; slegs gekanselleerde teks is ondeursigtig. Iemand wat die lêer oor vyf jaar vind, sonder die toepassing, kan presies sien hoe dit verseël is en dit oopmaak met OpenSSL of enige Argon2-biblioteek.
Formaat v1 (versend in 1.0, bly leesbaar)
{
"format": "authbackup",
"version": 1,
"kdf": "PBKDF2-HMAC-SHA256",
"rounds": 600000,
"salt": "<base64, 16 bytes>",
"cipher": "AES-256-GCM",
"nonce": "<base64, 12 bytes>",
"ciphertext": "<base64>",
"tag": "<base64, 16 bytes>"
}| Stap | Grepe |
|---|---|
key | PBKDF2-HMAC-SHA256(passphrase as UTF-8, salt, 600000 rounds, 32 bytes) |
aad | UTF-8("authbackup:1:600000:") ‖ salt (rou soutgrepe, nie base64 nie) |
ciphertext, tag | AES-256-GCM(key, nonce, plaintext, aad); etiket 16 grepe, apart gestoor |
plaintext | UTF-8 JSON, sleutels gesorteer: {"accounts":[…],"exportedAt":"…Z","passwords":[…],"version":1} |
Verenigbaarheidsnota: Android 1.0 het 'n variant van v1 geskryf — kdf in kleinletters, geen etiketsleutel (die 16-greep-etiket wat by die gekisfereerde teks gevoeg is), geen bykomende data nie. Beide platforms hou aan om daardie lêers te lees (wanneer die etiket afwesig is: verdeel die laaste 16 grepe, maak oop met 'n leë AAD; vergelyk kdf sonder om hoofletters te gebruik) en albei skryf nou slegs die uitleg hierbo.
Formaat v2 (huidig; die verstekwaarde vir nuwe rugsteun)
{
"format": "authbackup",
"version": 2,
"kdf": "Argon2id",
"memoryKiB": 65536,
"passes": 3,
"lanes": 1,
"salt": "<base64, 16 bytes>",
"cipher": "AES-256-GCM",
"nonce": "<base64, 12 bytes>",
"ciphertext": "<base64>",
"tag": "<base64, 16 bytes>"
}| Stap | Grepe |
|---|---|
key | Argon2id(version 0x13, passphrase as UTF-8, salt, m = 65536 KiB, t = 3, p = 1, tagLength 32, no secret, no associated data) |
aad | UTF-8("authbackup:2:argon2id:65536:3:1:") ‖ salt |
ciphertext, tag | AES-256-GCM(key, nonce, plaintext, aad); etiket 16 grepe, apart gestoor |
plaintext | UTF-8 JSON, sleutels gesorteer: {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2} |
Argon2id is die verwysing C-implementering (phc-winner-argon2, CC0), wat op beide platforms gelewer word. 64 MiB en 3 deurgange neem ongeveer 'n sekonde op 'n huidige foon en maak dat elke raaiskoot daardie geheue en tyd op enige hardeware kos - die eienskap wat PBKDF2 teen GPU-rigs kortkom, en die rede waarom v2 bestaan. 'n Leser ignoreer sleutels wat dit nie ken nie, so 'n v1-leser met 'n v2-liggaam sien eenvoudig nooit kaarte nie.
Bewys
Drie toetsvektorlêers (rugsteun v1, rugsteun v2 en Argon2id) word gegenereer deur 'n derde implementering, onafhanklik van beide toepassings (Node se OpenSSL vir PBKDF2 en AES-GCM, 'n WebAssembly Argon2id wat tydens generering gekontroleer is teen die gepubliseerde antwoorde van die verwysingsimplementering). Elk bevat die wagwoordfrase, sout, nonce, gewone teks, afgeleide sleutel, AAD, verwagte syferteks en etiket, en die volledige lêer. Die eenheidstoetse op iOS en op Android lees dieselfde lêers en beweer dieselfde grepe - dus word 'n rugsteun wat op een platform verseël is, bewys, nie aanvaar nie, om op die ander oop te maak, en 'n ooreenstemming van al drie is nie twee kopieë van dieselfde fout nie. 'n Metgesel-instrument maak 'n lêer oop wat 'n foon eintlik met dieselfde derde implementering geskryf het en kontroleer die opskrif teen die reëls hierbo (presies die formaat se sleutels, so geen wenk of naam kan teenwoordig wees nie; 16-greep sout, 12-greep nonce, 16-greep etiket apart gestoor; weergawe 2 teen presies 64 MiB / 3 / 1; die verkeerde wagwoordfrase geweier); die outomatiese iOS-lopie skryf een op die simulator en maak dit so oop, en deursoek die simulator se toepassinghouer, toepassinggroephouer en sleutelhangerdatabasis vir elke gesaaide wagwoord en kaartnommer as UTF-8 en UTF-16 (0 treffers).
4. Bedreigingsmodel
| Situasie | Wat hulle het | Wat hulle kry |
|---|---|---|
| Verlore of gesteelde foon, gesluit | Wat hulle hetDie toestel, die databasislêer, die verseëlde rye | Wat hulle kryGekodeerde teks. Die omhulselsleutel is in die Secure Enclave / StrongBox en word eers vrygestel nadat die toestel gesluit is plus 'n nuwe biometriese nommer of wagwoord. As die foon op afstand uitgevee word (Vind My / Vind My Toestel) word die sleutelmateriaal daarmee saam vernietig. |
| Gesteelde rugsteunlêer | Wat hulle hetDie .authbackup-lêer vanaf 'n wolkrekening, 'n e-pos, 'n skootrekenaar | Wat hulle kry'n AES-256-GCM-liggaam onder 'n sleutel afgelei van 'n wagwoordfrase van ten minste 12 karakters, met 'n per-lêer sout en Argon2id teen 64 MiB × 3 passe (v2) of PBKDF2 teen 600 000 rondtes (v1). Geen wenk, geen gebruikersnaam, geen rekeninglys in die oopte nie. Elke raaiskoot kos die volle afleiding; daar is geen kortpad nie. 'n Sterk wagwoordfrase is die hele verdediging hier, en die toepassing sê so op die blad. |
| Gesteelde toestel met die skerm ontsluit | Wat hulle het'n Foon in jou hand, ontsluit | Wat hulle kryDie Kodeslys. Die kluis (wagwoorde, kaarte) is agter die toepassingslot en sluit weer op die outomatiese sluit-timer (onmiddellik / 1 min / 5 min); 'n gedekripteerde waarde bestaan slegs in die geheue terwyl die skerm dit wys. Outomatiese invul en gewone teks-uitvoer vra vir 'n vars biometriese nommer selfs wanneer die toepassing oop is. Skakel toepassingslot aan met "Onmiddellik" as dit die geval is waaroor jy bekommerd is. |
| Kwaadwillige toepassing op dieselfde foon | Wat hulle het'n Ander toepassing se sandput, die knipbord, toeganklikheid of oorleg-truuks | Wat hulle kryDit kan nie ons lêers lees nie (platform-sandboxing) of ons sleutel gebruik nie (die sleutel is gekoppel aan ons ondertekeningsidentiteit en aan gebruikersteenwoordigheid). Kopieë word na 30 sekondes van die knipbord verwyder; op Android word die kopie as sensitief gemerk en van die knipbordgeskiedenis uitgesluit. Kluisskerms stel FLAG_SECURE op Android (geen skermkiekies, geen skermopname, leeg in die skakelaar); iOS maak die skakelaar-miniatuur leeg. Outomatiese invul op Android word slegs bedien aan programme wat die stelsel teen die gestoorde domein geverifieer het (Digitale Bateskakels), so 'n soortgelyke program word nie jou wagwoord aangebied nie. |
| Phishing-bladsy | Wat hulle het'n Webwerf wat lyk soos die een wat jy gestoor het | Wat hulle kryNiks vul nie. Ooreenstemming is volgens registreerbare domein (publieke agtervoegsellys, saamgevoeg en opgedateer met die toepassing): login.example.com en example.com stem ooreen, example.com.evil.net en examp1e.com nie. Die in-toepassing blaaier stem op dieselfde manier ooreen en vul slegs die raam in wat gevra het, weer gekontroleer teen daardie raam se eie oorsprong op die oomblik van die invul; 'n gasheer sonder sy eie registreerbare domein - 'n IP-adres, 'n blote naam op die plaaslike netwerk - stem presies ooreen en niks losser nie. iOS AutoFill voeg Apple se geassosieerde domeine-kontrole by. 'n Wagwoord wat jy met die hand in 'n soortgelyke wagwoord moet plak, is steeds 'n risiko; die toepassing kan dit nie verwyder nie, net vermy om te help. |
| Ons eie bedieners | Wat hulle het— | Wat hulle kryDaar is geen kluisbediener nie. AssuredAuth het geen rekeninge, geen aanmelding en geen kopie van jou kluis nie, so daar is niks van joune aan ons kant om gesteel en gekraak te word nie. Twee dinge loop wel aan die bedienerkant, en nie een van hulle raak die kluis nie: 'n aflosposbus vir die lessenaaruitbreiding, wat end-tot-end geïnkripteerde koeverte stoor (eenmalige kodes, uitgevee wanneer dit gelees word; die aflos het nooit 'n sleutel nie), en die opsionele privaatverbinding se uitgangsbedieners, wat verkeer dra en geen toegangslogboeke hou nie. |
| 'n Dagvaarding of 'n versoek van die regering | Wat hulle hetRegsproses aan ons gerig | Wat hulle kryNiks om oor te gee nie: ons besit geen kluis, geen sleutel, geen wagwoordfrase en geen rugsteun nie. Ons kan gedwing word om dit te sê; ons kan nie gedwing word om te produseer wat nie bestaan nie. |
5. Klembord, skermkiekies en geheue
- Kopieer plaas die waarde vir 30 sekondes op die knipbord, en vee dit dan uit as dit steeds ons s'n is. Op Android word die snit gemerk as EXTRA_IS_SENSITIVE, so die stelsel versteek dit van die knipbordvoorskou en -geskiedenis; op iOS is die plakbord-item slegs plaaslik (nie oorhandig aan ander toestelle nie).
- Kluisskerms (Wagwoorde, Wagwoord, Kaarte, Kaart, die wagwoordfraseblaaie, gewone teksuitvoer) stel FLAG_SECURE op Android. iOS het geen ekwivalente vlag nie; die toepassing maak sy miniatuur in die toepassingwisselaar leeg en die waardes is standaard agter 'n oogskakelaar.
- Gedekripteerde waardes leef slegs in die geheue terwyl 'n skerm dit wys en word verwyder wanneer dit weggaan of die toepassing sluit. Die datasleutel word vir 'n versoek uitgepak en nie oor die slot gekas nie.
- Gewone teks-uitvoer bestaan (so jy kan altyd vertrek) en is agter 'n bevestigingsblad en 'n vars biometriese nommer, en die skerm is ook FLAG_SECURE.
6. Outomatiese invul: wat vul, en wat nie
| Waar | Wagwoorde | Kaarte |
|---|---|---|
| iOS: Safari en programme (AutoFill-uitbreiding) | WagwoordeJa, na 'n nuwe Face ID / Touch ID / wagwoord in die uitbreiding (LAContext), en slegs vir die registreerbare domein waarvoor die inskrywing gestoor is, met Apple se geassosieerde domeine-kontrole vir programme. | KaarteNee. Kaart outomatiese invul in Safari is slegs Apple s'n; die kaartskerm sê "Vul die AssuredAuth-blaaier in en met kopie" en belowe niks anders nie. |
| Android: programme en Chrome (AutofillService) | WagwoordeJa, per-datastel-verifikasie: die stelsel wys BiometricPrompt voor die invul; toepassingspakket pas slegs wanneer Digital Asset Links dit aan die gestoorde domein koppel. | KaarteJa, die kredietkaartnommer, kredietkaartvervaldatum* en kredietkaartsekuriteitskode-wenke, dieselfde biometriese hek |
| Die AssuredAuth-blaaier (beide platforms) | WagwoordeJa, per registreerbare domein — 'n gasheer met geeneen van sy eie ooreenstemmings presies nie — in die raam wat gevra het, biometries voor die invulsel | KaarteJa, deur veldopsporing, biometries voor die vulling |
| Kopieer knoppies | WagwoordeAgter die toepassingslot, 30-sekonde knipbord | KaarteNommer, vervaldatum, CVC (dieselfde reëls) |
Niks vul op 'n soortgelyke gasheer nie. Niks vul sonder die biometrie nie.
7. Wat nooit gebeur nie
Geen kluisbediener nie. Geen analise wat 'n kluisveld dra nie. Geen gewone teks-uitvoer sonder 'n bevestigingsblad en 'n vars biometriese funksie nie. Geen derdeparty-SDK gelaai op 'n kluisskerm nie. Geen skermkiekie van 'n kluisskerm nie. Geen wagwoordfrase-wenk nie. Geen logging van waardes in enige bou nie.
8. Waarteen ons ons nie kan beskerm nie
'n Wagfrase wat swak genoeg is om te raai. 'n Foon waarvan die bedryfstelsel by die wortel gekompromitteer is (’n toestel met tronkstraf of wortels kan vir die toepassing lieg oor alles hierbo). 'n Persoon wat dopgehou word terwyl hy tik. Wanware op die lessenaar waarin jy plak. Ons sê dit sodat die lys hierbo gelees word vir wat dit is: die dinge wat 'n ontwerp kan verwyder, verwyder.
9. Hersien status
Hierdie ontwerp is eenheidsgetoets teen gepubliseerde bekende antwoorde op beide platforms en teen sy eie kruisplatformvektore. 'n Eksterne hersiening is op die eienaar se lys voordat die kluis op die winkellys geadverteer word; totdat dit gebeur het, sal hierdie dokument dit hier aandui.
10. Waar dinge loop
Niks van die kluis verlaat die foon nie, maar 'n paar dinge daaromheen loop wel op ander mense se masjiene. Hier is die lys, en wat elkeen bevat; die datavloei self word beskryf in die privaatheidsbeleid by https://assuredauth.com/privacy.
- Google Cloud / Firebase — die aflosposbus vir die lessenaaruitbreiding (end-tot-end geïnkripteerde koeverte, uitgevee wanneer gelees), stoottokens, aankoopstatus en die boodskappe wat deur die kontakvorm gestuur word.
- Vercel — assuredauth.com, sy bladsye en die klein funksies daaragter.
- Vultr — die privaat verbinding se uitgangsbedieners. Verkeer gaan deur hulle; niks word gestoor nie.
- Apple en Google Play — aankope en intekeninge, in hul eie winkels.
- PostHog — produkontleding: tellings van wat gebruik word, gekoppel aan geen identiteit nie.
- RevenueCat — die status van 'n intekening: aktief of verval, en op watter plan.
Elkeen bevat wat sy lyn sê en niks van die kluis nie. Die lys verander wanneer die produk dit doen, en hierdie afdeling verander daarmee saam.
Rapportering van 'n swakheid
As jy glo jy het 'n swakpunt gevind in enigiets wat hier beskryf word, skryf aan hello@assuredauth.com met die onderwerp "Sekuriteit". Sluit asseblief die platform, die toepassingsweergawe en die stappe in; 'n bewys wat jou eie data gebruik, is genoeg, en ons vra dat jy nie teen ander mense s'n toets nie. Ons bied nie 'n PGP-sleutel aan nie; as 'n verslag nie in gewone e-pos behoort te reis nie, sê dit in 'n eerste boodskap en ons reël 'n ander manier.
Wat ons in ruil daarvoor belowe: ons erken binne drie werksdae, hou jou op hoogte terwyl ons daaraan werk, maak reg wat werklik is voordat enigiets daaroor gepubliseer word, en gee jou hier krediet as jy krediet wil ontvang. Ons sal geen regstappe doen oor navorsing wat te goeder trou binne die onderstaande bestek gedoen is nie.
In omvang: die iOS- en Android-programme, die horlosie-programme, die lessenaaruitbreiding, assuredauth.com en sy API. Buite omvang: die App Store en Google Play self, die verskaffers wat hierbo gelys word, sosiale manipulasie van enigiemand, en diensweigering.
Daar is tans geen beloning nie. 'n Rapport word beantwoord met 'n regstelling en 'n dankie, nie met geld nie.