Sikkerhed
Hvordan boksen er bygget, og hvad et brud ville finde.
Sidst opdateret 21. september 2026 · AssuredAuth, af CircleRoll LLC
Dette er den offentlige beskrivelse af, hvordan AssuredAuth beskytter de tofaktorhemmeligheder, adgangskoder og kort, du opbevarer i den. Den er skrevet, så en sikkerhedsbevidst læser kan kontrollere alle påstande mod appen og mod de offentliggjorte testvektorer (tilgængelige for enhver anmelder på anmodning på hello@assuredauth.com). Den siger, hvad der er sandt, og intet mere: intet her hævdes at være uangribeligt, og intet er lovet i procenter.
Den korte version: Hvælvingen findes ét sted, din telefon. Enhver værdi i den er krypteret med en nøgle, som telefonens sikkerhedshardware indeholder og ikke kan eksportere. Vi kører ingen hvælvingsserver, indeholder ingen kopi og indeholder ingen nøgle. En backupfil forlader først telefonen, efter den er blevet krypteret under en adgangskode, der aldrig gemmes nogen steder.
Rapportér et problem: hello@assuredauth.com. Se "Rapportering af en svaghed" til sidst.
1. Hvad er krypteret, med hvad
| Data | På telefonen | Nøgle |
|---|---|---|
| To-faktor hemmeligheder (TOTP/HOTP/Steam-frø) | På telefonenNøglering (iOS) / Android Keystore-støttet butik | NøglePlatformens hardwarebundne nøgle; databaserækken indeholder kun en reference (secretRef), aldrig seed-koden. |
| Adgangskoder (adgangskoden, noter) | På telefonenForseglet række: AES-256-GCM, en tilfældig 96-bit nonce pr. værdi | NøgleEn tilfældig 256-bit datanøgle, der selv er indkapslet i hardwarenøglen i §2 |
| Kort (nummer, udløb, navn på kort, CVC) | På telefonenSamme segl som adgangskoder; CVC-koden er valgfri og gemmes kun, hvis du indtaster den | NøgleSamme datanøgle |
| Metadata (tjenestenavne, brugernavne, ikoner, sorteringsrækkefølge) | På telefonenAppens database (SwiftData / Room) | NøgleBeskyttet af operativsystemets filkryptering; behandlet som ikke-hemmelig |
| Backupfil (.authbackup) | På telefonenUanset hvor du placerer det: Filer, iCloud Drive, Google Drive appDataFolder, et delingsark | NøgleEn nøgle afledt af din adgangskode (§3). Apple og Google modtager den forseglede fil og intet andet |
| Ledsager til Watch/Wear | På telefonenUrets egen nøglering / EncryptedSharedPreferences | NøgleUrplatformens nøgler; overført via platformens parrede enhedskanal |
| Trafik til desktopudvidelser (engangskoder på forespørgsel) | På telefonenIkke gemt; videresendt som end-to-end krypterede kuverter | NøgleEt X25519-nøglepar pr. parring, privat nøgle i nøgleringen/nøglelageret; relæet ser kun krypteret tekst |
Diagnostik har ingen metode, der accepterer en hemmelighed. Ingen analysehændelse bærer et vault-felt. Ingen værdi fra vaulten skrives nogensinde til en log, i noget build.
2. Hvor nøglerne befinder sig, på hver platform
iOS. Datanøglen er pakket ind i en nøgle genereret i Secure Enclave (kSecAttrTokenIDSecureEnclave) med adgangskontrollen .privateKeyUsage + .userPresence, accessibility …ThisDeviceOnly, i appens delte nøgleringsadgangsgruppe, så AutoFill-udvidelsen kan bruge den samme nøgle. Den private nøgle kan ikke læses ud af Enclave af appen, af en sikkerhedskopi eller af en debugger; Enclave accepterer kun at bruge den, når brugeren er til stede (Face ID, Touch ID eller enhedens adgangskode). ThisDeviceOnly betyder, at en iCloud- eller iTunes-sikkerhedskopi af telefonen ikke indeholder nøglen; en gendannet telefon starter med en tom boks og beder om din sikkerhedskopifil og adgangskode. En telefon uden adgangskode kan ikke oprette en .userPresence-nøgle (Enclave nægter at oprette en), og simulatoren tager den samme vej per design (dens tilstedeværelsesprompt er en advarsel, som ingen test kan besvare): der er datanøglen et almindeligt enhedsnøgleringselement - stadig ude af alle sikkerhedskopier, stadig ulæseligt, mens telefonen er låst, men uden en anden prompt - og sikkerhedsskærmen siger præcis det og foreslår at indstille en adgangskode.
Android. Datanøglen er pakket ind i en AndroidKeyStore AES-256-nøgle, genereret i StrongBox, når enheden har en (ellers TEE), med setUserAuthenticationRequired(true) og en 30-sekunders godkendelsesgyldighed efter en biometrisk kode eller enhedslegitimation, setUnlockedDeviceRequired(true) og setInvalidatedByBiometricEnrollment(true) aktiveret. Det sidste flag er ærligt snarere end bærende: Android anvender det kun på nøgler, der kræver en biometrisk kode ved hver brug, så på denne 30-sekunders nøgle med enhedslegitimationen tilladt ændrer det ingenting - det, der holder en fremmeds finger ude, er, at tilmelding kræver PIN-koden, og at fjernelse af skærmlåsen ugyldiggør nøglen permanent. Keystore-nøgler kan ikke eksporteres og er udelukket fra Androids cloud-backup. Et domæne, som en app navngiver i sine egne visninger (webDomain), menes kun fra en kendt browser; fra enhver anden pakke skal det også være et, som systemet har verificeret for den pakke (Digital Asset Links), da enhver app kan gøre krav på ethvert domæne.
Hvad dette betyder for en stjålet databasefil. SQLite-filen og de forseglede rækker er krypteret tekst. Nøglen, der åbner dem, findes i sikkerhedshardwaren på den telefon, filen stammer fra, og kan ikke kopieres med filen. Der er intet at gætte offline: datanøglen er tilfældig og stammer ikke fra noget, en person har valgt.
3. Backupfilen
Backups er det eneste, der forlader telefonen, så de er det eneste sted, hvor et offlineangreb i princippet er muligt. Designet gør angrebet dyrt og giver den så lidt at arbejde med som muligt:
- Adgangskoden er mindst 12 tegn lang (arket afviser færre og viser en styrkebjælke).
- Der gemmes ikke noget hint til adgangssætningen nogen steder, hverken i filen eller i appen.
- Et nyt tilfældigt 16-byte salt og 12-byte nonce for hver skrevet fil.
- Hele indholdet er AES-256-GCM, så en forkert adgangskode eller en beskadiget fil afvises og dekrypteres aldrig som skrald.
- Headeren (format, version, KDF-parametre, salt) er bundet til GCM-tagget som yderligere autentificerede data, så en fil, hvis arbejdsfaktor er blevet redigeret ned, åbnes ikke.
Filen er JSON og kan læses i enhver teksteditor; kun krypteret tekst er uigennemsigtig. En person, der finder filen om fem år, hvor appen er væk, kan se præcis, hvordan den blev forseglet, og åbne den med OpenSSL eller et hvilket som helst Argon2-bibliotek.
Format v1 (leveret i 1.0, forbliver læsbar)
{
"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>"
}| Trin | Bytes |
|---|---|
key | PBKDF2-HMAC-SHA256(passphrase as UTF-8, salt, 600000 rounds, 32 bytes) |
aad | UTF-8("authbackup:1:600000:") ‖ salt (rå saltbytes, ikke base64) |
ciphertext, tag | AES-256-GCM(key, nonce, plaintext, aad); tag 16 bytes, gemt separat |
plaintext | UTF-8 JSON, nøgler sorteret: {"accounts":[…],"exportedAt":"…Z","passwords":[…],"version":1} |
Kompatibilitetsnote: Android 1.0 skrev en variant af v1 — kdf med små bogstaver, ingen tag-nøgle (16-byte-tagget tilføjet til krypteret tekst), ingen yderligere data. Begge platforme fortsætter med at læse disse filer (når tagget mangler: opdel de sidste 16 bytes, åbn med tom AAD; sammenlign kdf uden at skelne mellem store og små bogstaver), og begge skriver nu kun layoutet ovenfor.
Format v2 (nuværende; standardindstillingen for nye sikkerhedskopier)
{
"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>"
}| Trin | Bytes |
|---|---|
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); tag 16 bytes, gemt separat |
plaintext | UTF-8 JSON, nøgler sorteret: {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2} |
Argon2id er reference C-implementeringen (phc-winner-argon2, CC0), der leveres på begge platforme. 64 MiB og 3 gennemløb tager cirka et sekund på en nuværende telefon, og hvert gæt koster den hukommelse og tid på al hardware – den egenskab, som PBKDF2 mangler mod GPU-rigge, og grunden til, at v2 eksisterer. En læser ignorerer nøgler, den ikke kender, så en v1-læser med et v2-kabinet ser simpelthen aldrig kort.
Bevis
Tre testvektorfiler (backup v1, backup v2 og Argon2id) genereres af en tredje implementering, uafhængigt af begge apps (Nodes OpenSSL til PBKDF2 og AES-GCM, en WebAssembly Argon2id kontrolleret på genereringstidspunktet mod referenceimplementeringens publicerede svar). Hver indeholder adgangskode, salt, nonce, klartekst, afledt nøgle, AAD, forventet krypteringstekst og tag samt den komplette fil. Enhedstestene på iOS og Android læser de samme filer og bekræfter de samme bytes - så en backup, der er forseglet på én platform, er bevist, ikke antaget, at åbne på den anden, og en overensstemmelse mellem alle tre er ikke to kopier af den samme fejl. Et tilhørende værktøj åbner en fil, som en telefon rent faktisk har skrevet med den samme tredje implementering, og kontrollerer headeren mod ovenstående regler (præcis formatets nøgler, så der må ikke være noget hint eller navn til stede; 16-byte salt, 12-byte nonce, 16-byte tag gemt separat; version 2 på præcis 64 MiB / 3 / 1; den forkerte adgangskode afvist); den automatiserede iOS-kørsel skriver en fil på simulatoren og åbner den på den måde, og søger i simulatorens appcontainer, appgruppecontainer og nøgleringsdatabase for hver seedet adgangskode og kortnummer som UTF-8 og UTF-16 (0 hits).
4. Trusselsmodel
| Situation | Hvad de har | Hvad de får |
|---|---|---|
| Mistet eller stjålet telefon, låst | Hvad de harEnheden, databasefilen, de forseglede rækker | Hvad de fårKrypteret tekst. Indpakningsnøglen er i Secure Enclave / StrongBox og frigives først efter enhedens låsning plus en ny biometrisk kode eller adgangskode. Fjernsletning af telefonen (Find min / Find min enhed) ødelægger nøglematerialet sammen med den. |
| Stjålet backupfil | Hvad de har.authbackup-filen fra en cloud-konto, en e-mail, en bærbar computer | Hvad de fårEn AES-256-GCM-krop under en nøgle afledt af en adgangskode på mindst 12 tegn, med et salt pr. fil og Argon2id ved 64 MiB × 3 gennemløb (v2) eller PBKDF2 ved 600.000 runder (v1). Intet hint, intet brugernavn, ingen kontoliste i det fri. Hvert gæt koster den fulde afledning; der er ingen genvej. En stærk adgangskode er hele forsvaret her, og appen siger det på arket. |
| Stjålet enhed med ulåst skærm | Hvad de harEn telefon i din hånd, ulåst | Hvad de fårKodelisten. Hvælvingen (adgangskoder, kort) er bag applåsen og låser igen ved hjælp af den automatiske låsetimer (straks / 1 min / 5 min); en dekrypteret værdi findes kun i hukommelsen, mens skærmen viser den. Autoudfyldning og eksport i almindelig tekst beder om en ny biometrisk værdi, selv når appen er åben. Slå applås til med "Straks", hvis dette er tilfældet, du er bekymret for. |
| Ondsindet app på den samme telefon | Hvad de harEn anden apps sandkasse, udklipsholderen, tilgængelighed eller overlay-tricks | Hvad de fårDen kan ikke læse vores filer (platformsandboxing) eller bruge vores nøgle (nøglen er bundet til vores signeringsidentitet og brugerens tilstedeværelse). Kopier slettes fra udklipsholderen efter 30 sekunder; på Android markeres kopien som følsom og ekskluderes fra udklipsholderhistorikken. Vault-skærme er indstillet til FLAG_SECURE på Android (ingen skærmbilleder, ingen skærmoptagelse, tom i switcher); iOS tømmer switcher-miniaturebilledet. Autoudfyldning på Android vises kun til apps, som systemet har verificeret mod det gemte domæne (Digital Asset Links), så en lignende app får ikke tilbudt din adgangskode. |
| Phishing-side | Hvad de harEn hjemmeside, der ligner den, du gemte | Hvad de fårIntet udfyldes. Matchning sker efter registrerbart domæne (offentlig suffiksliste, bundtet og opdateret med appen): login.example.com og example.com matcher, example.com.evil.net og examp1e.com gør ikke. Browseren i appen matcher på samme måde og udfylder kun den frame, der spurgte, kontrolleret igen mod den frames egen oprindelse på udfyldningstidspunktet; en vært uden sit eget registrerbare domæne - en IP-adresse, et rent navn på det lokale netværk - matcher nøjagtigt og intet løsere. iOS AutoFill tilføjer Apples kontrol af tilknyttede domæner. En adgangskode, du skal indsætte manuelt i en look-alike, er stadig en risiko; appen kan ikke fjerne det, kun undgå at hjælpe. |
| Vores egne servere | Hvad de har— | Hvad de fårDer er ingen hvælvingsserver. AssuredAuth har ingen konti, intet login og ingen kopi af din hvælving, så der er intet af din på vores side, der kan stjæles og knækkes. To ting kører på serversiden, og ingen af dem berører hvælvingen: en relæpostkasse til desktopudvidelsen, som gemmer end-to-end-krypterede kuverter (engangskoder, der slettes, når de læses; relæet har aldrig en nøgle), og den valgfrie private forbindelses exit-servere, som bærer trafik og ikke fører adgangslogfiler. |
| En stævning eller en anmodning fra regeringen | Hvad de harJuridisk proces rettet mod os | Hvad de fårIntet at udlevere: vi har ingen hvælving, ingen nøgle, ingen adgangskode og ingen backup. Vi kan tvinges til at sige det; vi kan ikke tvinges til at producere noget, der ikke eksisterer. |
5. Udklipsholder, skærmbilleder og hukommelse
- Kopiering placerer værdien i udklipsholderen i 30 sekunder og sletter den derefter, hvis den stadig er vores. På Android er klippet markeret som EXTRA_IS_SENSITIVE, så systemet skjuler det fra udklipsholderens forhåndsvisning og historik; på iOS er montagebordelementet kun lokalt (ikke overdraget til andre enheder).
- Hjælpeskærme (Adgangskoder, Adgangskode, Kort, Kort, adgangsfraseark, eksport af almindelig tekst) sætter FLAG_SECURE på Android. iOS har intet tilsvarende flag; appen blanker sit miniaturebillede i app-skifteren, og værdierne vises som standard bag en øje-knap.
- Dekrypterede værdier gemmes kun i hukommelsen, mens de vises på en skærm, og slettes, når den forsvinder, eller appen låser. Datanøglen udpakkes til en anmodning og caches ikke på tværs af låsen.
- Eksport af almindelig tekst findes (så du altid kan forlade) og er bag et bekræftelsesark og en frisk biometrisk kode, og dens skærm er også FLAG_SECURE.
6. Autoudfyldning: hvad udfyldes, og hvad ikke
| Hvor | Adgangskoder | Kort |
|---|---|---|
| iOS: Safari og apps (AutoFill-udvidelse) | AdgangskoderJa, efter en ny Face ID / Touch ID / adgangskode i udvidelsen (LAContext), og kun for det registrerbare domæne, som posten blev gemt for, med Apples tjek af tilknyttede domæner for apps. | KortNej. Autoudfyldning af kort i Safari er udelukkende fra Apple; kortskærmen viser "Udfylder AssuredAuth-browseren og med kopi" og lover intet andet. |
| Android: apps og Chrome (AutofillService) | AdgangskoderJa, godkendelse pr. datasæt: systemet viser BiometricPrompt før udfyldningen; app-pakken matches kun, når Digital Asset Links knytter den til det gemte domæne. | KortJa, hints til creditCardNumber, creditCardExpiration* og creditCardSecurityCode, samme biometriske gate |
| AssuredAuth-browseren (begge platforme) | AdgangskoderJa, via registrerbart domæne — en vært uden præcise matches — ind i den ramme, der spurgte, biometrisk før udfyldningen | KortJa, via feltdetektion, biometrisk før udfyldning |
| Kopier knapper | AdgangskoderBag applåsen, 30-sekunders udklipsholder | KortNummer, udløb, CVC (samme regler) |
Intet udfylder en vært, der ligner en anden. Intet udfylder uden biometri.
7. Hvad der aldrig sker
Ingen vault-server. Ingen analyser, der indeholder et vault-felt. Ingen eksport i almindelig tekst uden et bekræftelsesark og en frisk biometrisk værdi. Ingen tredjeparts-SDK indlæst på en vault-skærm. Intet skærmbillede af en vault-skærm. Intet tip til adgangskode. Ingen logføring af værdier i nogen builds.
8. Hvad vi ikke kan beskytte os imod
En adgangskode, der er svag nok til at kunne gættes. En telefon, hvis operativsystem er kompromitteret i roden (en jailbroken eller rootet enhed kan lyve til appen om alt ovenstående). En person, der bliver overvåget, mens den skriver. Malware på skrivebordet, du indsætter på. Vi siger dette, så listen ovenfor læses for, hvad den er: de ting, et design kan fjerne, fjernes.
9. Gennemgå status
Dette design er blevet enhedstestet mod publicerede kendte svar på begge platforme og mod dets egne tværplatformsvektorer. En ekstern gennemgang er på ejerens liste, før hvælvet annonceres på butiksprofilen. Indtil det er sket, vil dette dokument angive det her.
10. Hvor tingene kører
Intet fra hvælvet forlader telefonen, men et par ting omkring den kører på andre personers maskiner. Dette er listen, og hvad hver enkelt indeholder; selve datastrømmene er beskrevet i privatlivspolitikken på https://assuredauth.com/privacy.
- Google Cloud/Firebase — relæpostkassen til desktopudvidelsen (end-to-end-krypterede kuverter, slettes ved læsning), push-tokens, købsstatus og beskeder sendt via kontaktformularen.
- Vercel — assuredauth.com, dens sider og de små funktioner bagved dem.
- Vultr — den private forbindelses exit-servere. Trafikken passerer gennem dem; intet gemmes.
- Apple og Google Play — køb og abonnementer i deres egne butikker.
- PostHog — produktanalyse: optælling af, hvad der bruges, uden identitet.
- RevenueCat — status for et abonnement: aktivt eller udløbet, og på hvilket abonnement.
Hver indeholder, hvad dens linje siger, og intet fra arkivet. Listen ændres, når produktet gør det, og dette afsnit ændres med det.
Rapportering af en svaghed
Hvis du mener, at du har fundet en svaghed i noget af det, der er beskrevet her, så skriv til hello@assuredauth.com med emnefeltet "Sikkerhed". Angiv venligst platformen, appversionen og trinnene; et bevis, der bruger dine egne data, er tilstrækkeligt, og vi beder dig om ikke at teste mod andres data. Vi tilbyder ikke en PGP-nøgle; hvis en rapport ikke skal sendes som almindelig e-mail, så skriv det i den første besked, så arrangerer vi en anden løsning.
Hvad vi lover til gengæld: Vi bekræfter inden for tre hverdage, holder dig informeret, mens vi arbejder på det, retter det, der er sandt, før noget om det offentliggøres, og krediterer dig her, hvis du ønsker at blive krediteret. Vi vil ikke anlægge sag mod forskning udført i god tro inden for nedenstående rammer.
Omfattet af: iOS- og Android-apps, ur-apps, desktopudvidelsen, assuredauth.com og dens API. Omfattet af: App Store og Google Play selv, de ovennævnte udbydere, social engineering af alle og denial of service.
Der er ingen dusør på nuværende tidspunkt. En anmeldelse besvares med en erstatning og en tak, ikke med penge.