Sikkerhet
Hvordan hvelvet er bygget, og hva et brudd ville avdekke.
Sist oppdatert 21. september 2026 · AssuredAuth, av CircleRoll LLC
Dette er den offentlige beskrivelsen av hvordan AssuredAuth beskytter tofaktorhemmelighetene, passordene og kortene du oppbevarer i den. Den er skrevet slik at en sikkerhetsbevisst leser kan sjekke alle påstander mot appen og mot de publiserte testvektorene (tilgjengelig for enhver anmelder på forespørsel på hello@assuredauth.com). Den sier det som er sant og ikke mer: ingenting her hevder å være uangripelig, og ingenting er lovet i prosent.
Kortversjonen: hvelvet finnes på ett sted, telefonen din. Hver verdi i det er kryptert med en nøkkel som telefonens sikkerhetsmaskinvare har og ikke kan eksportere. Vi kjører ingen hvelvserver, har ingen kopi og ingen nøkkel. En sikkerhetskopifil forlater telefonen først etter at den er kryptert under et passord som aldri lagres noe sted.
Rapporter et problem: hello@assuredauth.com. Se «Rapportering av svakhet» på slutten.
1. Hva er kryptert, med hva
| Data | På telefonen | Nøkkel |
|---|---|---|
| Tofaktorhemmeligheter (TOTP/HOTP/Steam-frø) | På telefonenNøkkelring (iOS) / Android Keystore-støttet butikk | NøkkelPlattformens maskinvarebundne nøkkel; databaseraden inneholder bare en referanse (secretRef), aldri frøet |
| Passord (passordverdien, merknader) | På telefonenForseglet rad: AES-256-GCM, en tilfeldig 96-bit nonce per verdi | NøkkelEn tilfeldig 256-bits datanøkkel, som selv er pakket inn i maskinvarenøkkelen i §2 |
| Kort (nummer, utløpsdato, navn på kort, CVC) | På telefonenSamme segl som passord; CVC-koden er valgfri og lagres bare hvis du skriver den inn | NøkkelSamme datanøkkel |
| Metadata (tjenestenavn, brukernavn, ikoner, sorteringsrekkefølge) | På telefonenAppens database (SwiftData / Room) | NøkkelBeskyttet av operativsystemets filkryptering; behandlet som ikke-hemmelig |
| Sikkerhetskopieringsfil (.authbackup) | På telefonenUansett hvor du plasserer det: Filer, iCloud Drive, Google Drive appDataFolder, et delingsark | NøkkelEn nøkkel utledet fra passordfrasen din (§3). Apple og Google mottar den forseglede filen og ingenting annet |
| Følgeapp for Watch/Wear | På telefonenKlokkens egen nøkkelring / EncryptedSharedPreferences | NøkkelKlokkeplattformens nøkler; overført via plattformens kanal for parede enheter |
| Trafikk for skrivebordsutvidelser (engangskoder på forespørsel) | På telefonenIkke lagret; videresendt som ende-til-ende-krypterte konvolutter | NøkkelEt X25519-nøkkelpar per paring, privat nøkkel i nøkkelringen/nøkkellageret; reléet ser bare kryptert tekst |
Diagnostikk har ingen metode som godtar en hemmelighet. Ingen analysehendelse bærer et hvelvfelt. Ingen verdi fra hvelvet skrives noen gang til en logg, i noen build.
2. Hvor nøklene befinner seg, på hver plattform
iOS. Datanøkkelen er pakket inn i en nøkkel generert i Secure Enclave (kSecAttrTokenIDSecureEnclave) med tilgangskontrollen .privateKeyUsage + .userPresence, accessibility …ThisDeviceOnly, i appens delte nøkkelringstilgangsgruppe, slik at AutoFill-utvidelsen kan bruke den samme nøkkelen. Den private nøkkelen kan ikke leses ut av Enclave av appen, av en sikkerhetskopi eller av en feilsøkingsfunksjon. Enclave samtykker bare i å bruke den etter at brukeren er til stede (Face ID, Touch ID eller enhetens passord). ThisDeviceOnly betyr at en iCloud- eller iTunes-sikkerhetskopi av telefonen ikke inneholder nøkkelen. En gjenopprettet telefon starter med et tomt hvelv og ber om sikkerhetskopifilen og passordfrasen din. En telefon uten passord kan ikke opprette en .userPresence-nøkkel (Enclave nekter å opprette en), og simulatoren tar samme vei per design (tilstedeværelsesspørsmålet er et varsel ingen test kan svare på): der er datanøkkelen et vanlig nøkkelringelement som bare er tilgjengelig for enheten – fortsatt ute av alle sikkerhetskopier, fortsatt uleselig mens telefonen er låst, men uten noen andre melding – og sikkerhetsskjermen sier nettopp det og foreslår å angi et passord.
Android. Datanøkkelen er pakket inn i en AndroidKeyStore AES-256-nøkkel, generert i StrongBox når enheten har en (ellers TEE), med setUserAuthenticationRequired(true) og en 30-sekunders autentiseringsgyldighet etter at en biometrisk kode eller enhetslegitimasjon, setUnlockedDeviceRequired(true) og setInvalidatedByBiometricEnrollment(true) er aktivert. Det siste flagget er ærlig snarere enn bærende: Android bruker det bare på nøkler som krever biometrisk kode ved hver bruk, så på denne 30-sekundersnøkkelen med enhetslegitimasjonen tillatt endrer det ingenting – det som holder en fremmed finger unna, er at registrering av en krever PIN-kode, og at fjerning av skjermlåsen ugyldiggjør nøkkelen for godt. Keystore-nøkler kan ikke eksporteres og er ekskludert fra Androids skysikkerhetskopi. Et domene en app navngir på sine egne visninger (webDomain) antas bare fra en kjent nettleser; fra enhver annen pakke må det også være et som systemet har bekreftet for den pakken (Digital Asset Links), siden enhver app kan gjøre krav på ethvert domene.
Hva dette betyr for en stjålet databasefil. SQLite-filen og de forseglede radene er kryptert tekst. Nøkkelen som åpner dem ligger i sikkerhetsmaskinvaren på telefonen filen kom fra, og kan ikke kopieres med filen. Det er ingenting å gjette offline: datanøkkelen er tilfeldig, ikke avledet fra noe en person har valgt.
3. Sikkerhetskopien
Sikkerhetskopier er det eneste som forlater telefonen, så de er det eneste stedet hvor et offline-angrep i prinsippet er mulig. Designet gjør det angrepet dyrt og gir den så lite å jobbe med som mulig:
- Passordfrasen er på minst 12 tegn (arket avviser færre og viser en styrkesøyle).
- Ingen passordhint lagres noe sted, verken i filen eller i appen.
- Et nytt, tilfeldig 16-byte salt og 12-byte nonce for hver fil som skrives.
- Hele filen er AES-256-GCM, så en feil passordfrase eller en skadet fil blir avvist og aldri dekryptert til søppel.
- Overskriften (format, versjon, KDF-parametere, salt) er bundet til GCM-taggen som ytterligere autentiserte data, slik at en fil med en nedjustert arbeidsfaktor ikke åpnes.
Filen er i JSON og kan leses i alle tekstredigeringsprogrammer; bare chiffertekst er ugjennomsiktig. Noen som finner filen om fem år, uten at appen er installert, kan se nøyaktig hvordan den ble forseglet og åpne den med OpenSSL eller et hvilket som helst Argon2-bibliotek.
Format v1 (levert i 1.0, forblir lesbar)
{
"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>"
}| Steg | Byte |
|---|---|
key | PBKDF2-HMAC-SHA256(passphrase as UTF-8, salt, 600000 rounds, 32 bytes) |
aad | UTF-8("authbackup:1:600000:") ‖ salt (rå saltbyte, ikke base64) |
ciphertext, tag | AES-256-GCM(key, nonce, plaintext, aad); tag 16 byte, lagret separat |
plaintext | UTF-8 JSON, nøkler sortert: {"accounts":[…],"exportedAt":"…Z","passwords":[…],"version":1} |
Kompatibilitetsmerknad: Android 1.0 skrev en variant av v1 – kdf med små bokstaver, ingen tagnøkkel (16-byte-taggen lagt til chiffertekst), ingen tilleggsdata. Begge plattformene fortsetter å lese disse filene (når taggen mangler: del de siste 16 bytene, åpne med tom AAD; sammenlign kdf uten å skille mellom store og små bokstaver), og begge skriver nå bare layouten ovenfor.
Format v2 (gjeldende; standard for nye sikkerhetskopier)
{
"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>"
}| Steg | Byte |
|---|---|
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 byte, lagret separat |
plaintext | UTF-8 JSON, nøkler sortert: {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2} |
Argon2id er referanseimplementeringen i C (phc-winner-argon2, CC0), som leveres på begge plattformene. 64 MiB og 3 passeringer tar omtrent et sekund på en nåværende telefon, og hver gjetning koster minne og tid på all maskinvare – egenskapen PBKDF2 mangler mot GPU-rigger, og grunnen til at v2 eksisterer. En leser ignorerer nøkler den ikke kjenner, så en v1-leser gitt en v2-kropp ser rett og slett aldri kort.
Bevis
Tre testvektorfiler (backup v1, backup v2 og Argon2id) genereres av en tredje implementering, uavhengig av begge appene (Nodes OpenSSL for PBKDF2 og AES-GCM, en WebAssembly Argon2id kontrollert ved generering mot referanseimplementeringens publiserte svar). Hver inneholder passordfrasen, salt, nonce, klartekst, avledet nøkkel, AAD, forventet kryptert tekst og tag, og den komplette filen. Enhetstestene på iOS og Android leser de samme filene og bekrefter de samme bytene – så en sikkerhetskopi som er forseglet på én plattform er bevist, ikke antatt, å åpne på den andre, og en samsvar mellom alle tre er ikke to kopier av samme feil. Et tilhørende verktøy åpner en fil som en telefon faktisk skrev med den samme tredje implementeringen og sjekker overskriften mot reglene ovenfor (nøyaktig formatets nøkler, så ingen hint eller navn kan være tilstede; 16-byte salt, 12-byte nonce, 16-byte tag lagret separat; versjon 2 på nøyaktig 64 MiB / 3 / 1; feil passordfrase avvist); den automatiserte iOS-kjøringen skriver en på simulatoren og åpner den på den måten, og søker i simulatorens appcontainer, appgruppecontainer og nøkkelringdatabase etter hvert seedede passord og kortnummer som UTF-8 og UTF-16 (0 treff).
4. Trusselmodell
| Situasjon | Det de har | Det de får |
|---|---|---|
| Mistet eller stjålet telefon, låst | Det de harEnheten, databasefilen, de forseglede radene | Det de fårKryptert tekst. Innpakningsnøkkelen er i Secure Enclave / StrongBox og utløses først etter at enheten er låst pluss en ny biometrisk kode eller passord. Fjernsletting av telefonen (Finn min / Finn enheten min) ødelegger nøkkelmaterialet sammen med den. |
| Stjålet sikkerhetskopifil | Det de har.authbackup-filen fra en skykonto, en e-post eller en bærbar PC | Det de fårEn AES-256-GCM-kropp under en nøkkel avledet fra en passfrase på minst 12 tegn, med et salt per fil og Argon2id ved 64 MiB × 3 passeringer (v2) eller PBKDF2 ved 600 000 runder (v1). Ingen hint, ingen brukernavn, ingen kontoliste i klartekst. Hver gjetning koster hele avledningen; det finnes ingen snarvei. En sterk passfrase er hele forsvaret her, og appen sier det på arket. |
| Stjålet enhet med skjermen ulåst | Det de harEn telefon i hånden din, ulåst | Det de fårKodelisten. Hvelvet (passord, kort) er bak applåsen og låses på nytt med automatisk låsetimer (umiddelbart / 1 min / 5 min); en dekryptert verdi finnes bare i minnet mens skjermen viser den. Autofyll og eksport i ren tekst ber om en ny biometrisk verdi selv når appen er åpen. Slå på applås med «Umiddelbart» hvis dette er tilfellet du er bekymret for. |
| Ondsinnet app på samme telefon | Det de harEn annen apps sandkasse, utklippstavlen, tilgjengelighet eller overleggstriks | Det de fårDen kan ikke lese filene våre (plattformsandkasse) eller bruke nøkkelen vår (nøkkelen er knyttet til signeringsidentiteten vår og brukerens tilstedeværelse). Kopier slettes fra utklippstavlen etter 30 sekunder; på Android flagges kopien som sensitiv og ekskluderes fra utklippstavlens historikk. Hvelvskjermer settes til FLAG_SECURE på Android (ingen skjermbilder, ingen skjermopptak, tomt i veksleren); iOS tømmer vekslerminiatyrbildet. Autofyll på Android leveres bare til apper som systemet har bekreftet mot det lagrede domenet (Digital Asset Links), slik at en lignende app ikke får tilbudt passordet ditt. |
| Phishing-side | Det de harEt nettsted som ser ut som det du lagret | Det de fårIngenting fylles ut. Samsvar skjer etter registrerbart domene (offentlig suffiksliste, samlet og oppdatert med appen): login.example.com og example.com samsvarer, example.com.evil.net og examp1e.com gjør ikke det. Nettleseren i appen samsvarer på samme måte og fyller bare inn i rammen som spurte, sjekket på nytt mot rammens egen opprinnelse i utfyllingsøyeblikket; en vert uten eget registrerbart domene – en IP-adresse, et rent navn på det lokale nettverket – samsvarer nøyaktig og ingenting løsere. iOS AutoFill legger til Apples sjekk av tilknyttede domener. Et passord du må lime inn for hånd i et liknende passord er fortsatt en risiko; appen kan ikke fjerne det, bare unngå å hjelpe. |
| Våre egne servere | Det de har— | Det de fårDet finnes ingen hvelvserver. AssuredAuth har ingen kontoer, ingen pålogging og ingen kopi av hvelvet ditt, så det er ingenting du eier på vår side som kan stjeles og knekkes. To ting kjører på serversiden, og ingen av dem berører hvelvet: en relépostkasse for skrivebordsutvidelsen, som lagrer ende-til-ende-krypterte konvolutter (engangskoder, slettes når de leses; reléet har aldri en nøkkel), og den valgfrie private tilkoblingens utgangsservere, som bærer trafikk og ikke fører tilgangslogger. |
| En stevning eller en anmodning fra myndighetene | Det de harRettslig prosess adressert til oss | Det de fårIngenting å gi fra oss: vi har ingen hvelv, ingen nøkkel, ingen passordfrase og ingen sikkerhetskopi. Vi kan bli tvunget til å si det; vi kan ikke bli tvunget til å produsere det som ikke eksisterer. |
5. Utklippstavle, skjermbilder og minne
- Kopier legger verdien på utklippstavlen i 30 sekunder, og fjerner den deretter hvis den fortsatt er vår. På Android er klippet merket EXTRA_IS_SENSITIVE, slik at systemet skjuler det fra forhåndsvisningen og historikken på utklippstavlen. På iOS er innkapslingselementet bare lokalt (ikke overlevert til andre enheter).
- Hvelvskjermer (Passord, Passord, Kort, Kort, passordfraseark, eksport av ren tekst) setter FLAG_SECURE på Android. iOS har ikke noe tilsvarende flagg; appen blanker miniatyrbildet i appveksleren, og verdiene vises bak en øyebryter som standard.
- Dekrypterte verdier lagres bare i minnet mens de vises på en skjerm, og slettes når minnet forsvinner eller appen låses. Datanøkkelen pakkes ut for en forespørsel og lagres ikke i mellomlagringen.
- Eksport av ren tekst finnes (slik at du alltid kan forlate den) og ligger bak et bekreftelsesark og en ny biometrisk kode, og skjermen er også FLAG_SECURE.
6. Autofyll: hva fylles ut, og hva fylles ikke ut
| Hvor | Passord | Kort |
|---|---|---|
| iOS: Safari og apper (Autofyll-utvidelse) | PassordJa, etter en ny Face ID / Touch ID / passord i utvidelsen (LAContext), og bare for det registrerbare domenet oppføringen ble lagret for, med Apples sjekk av tilknyttede domener for apper. | KortNei. Autoutfylling av kort i Safari er kun tilgjengelig for Apple; kortskjermen sier «Fyller ut AssuredAuth-nettleseren og med kopi» og lover ingenting annet. |
| Android: apper og Chrome (AutofillService) | PassordJa, autentisering per datasett: systemet viser BiometricPrompt før utfyllingen; apppakken samsvarer bare når Digital Asset Links knytter den til det lagrede domenet | KortJa, hintene for creditCardNumber, creditCardExpiration* og creditCardSecurityCode, samme biometriske port. |
| AssuredAuth-nettleseren (begge plattformer) | PassordJa, med registrerbart domene – en vert uten nøyaktige treff – inn i rammen som spurte, biometrisk før utfyllingen | KortJa, via feltdeteksjon, biometrisk før utfylling |
| Kopier knapper | PassordBak applåsen, 30-sekunders utklippstavle | KortNummer, utløpsdato, CVC (samme regler) |
Ingenting fyller en vert som ligner på hverandre. Ingenting fyller uten biometri.
7. Det som aldri skjer
Ingen hvelvserver. Ingen analyser som inneholder et hvelvfelt. Ingen eksport i ren tekst uten et bekreftelsesark og en ny biometrisk kode. Ingen tredjeparts SDK lastet inn på en hvelvskjerm. Ingen skjermbilde av en hvelvskjerm. Ingen passordhint. Ingen logging av verdier i noen build.
8. Hva vi ikke kan beskytte mot
En passordfrase som er svak nok til å gjettes. En telefon med et kompromittert operativsystem i rotmodus (en jailbroken eller rootet enhet kan lyve til appen om alt ovenfor). En person som blir overvåket mens de skriver. Skadelig programvare på skrivebordet du limer inn på. Vi sier dette slik at listen ovenfor leses for det den er: de tingene et design kan fjerne, fjernet.
9. Gjennomgangsstatus
Dette designet har blitt enhetstestet mot publiserte kjente svar på begge plattformer og mot sine egne kryssplattformvektorer. En ekstern gjennomgang står på eierens liste før hvelvet annonseres i butikkoppføringen. Inntil det har skjedd, vil dette dokumentet si det her.
10. Hvor ting kjører
Ingenting av hvelvet forlater telefonen, men noen ting rundt det kjører på andres maskiner. Dette er listen, og hva hver enkelt inneholder; selve datastrømmene er beskrevet i personvernerklæringen på https://assuredauth.com/privacy.
- Google Cloud / Firebase – relépostkassen for skrivebordsutvidelsen (ende-til-ende-krypterte konvolutter, slettes ved lesing), push-tokens, kjøpsstatus og meldingene som sendes via kontaktskjemaet.
- Vercel — assuredauth.com, sidene og de små funksjonene bak dem.
- Vultr — den private forbindelsens utgangsservere. Trafikken går gjennom dem; ingenting lagres.
- Apple og Google Play – kjøp og abonnementer, i egne butikker.
- PostHog – produktanalyse: tellinger av hva som brukes, uten identitet.
- RevenueCat – statusen til et abonnement: aktivt eller utløpt, og på hvilket abonnement.
Hver inneholder det linjen sier og ingenting fra hvelvet. Listen endres når produktet gjør det, og denne delen endres med det.
Rapportering av en svakhet
Hvis du mener du har funnet en svakhet i noe som er beskrevet her, kan du skrive til hello@assuredauth.com med emnefeltet «Sikkerhet». Vennligst inkluder plattform, appversjon og trinnene. Et bevis som bruker dine egne data er nok, og vi ber deg om å ikke teste mot andres data. Vi tilbyr ikke en PGP-nøkkel. Hvis en rapport ikke skal sendes i vanlig e-post, si det i en første melding, så ordner vi en annen løsning.
Det vi lover tilbake: Vi bekrefter søknaden innen tre virkedager, holder deg informert mens vi jobber med den, retter opp det som er ekte før noe publiseres, og krediterer deg her hvis du ønsker å bli kreditert. Vi vil ikke iverksette rettslige skritt mot forskning utført i god tro innenfor rammen nedenfor.
Omfatter: iOS- og Android-appene, klokkeappene, skrivebordsutvidelsen, assuredauth.com og API-en tilhørende. Utenfor omfang: App Store og Google Play selv, leverandørene som er oppført ovenfor, sosial manipulering av hvem som helst og tjenestenekt.
Det er ingen dusør for øyeblikket. En rapport besvares med en erstatning og en takk, ikke med penger.