Säkerhet

Hur valvet är byggt, och vad ett intrång skulle hitta.

Senast uppdaterad 21 september 2026 · AssuredAuth, av CircleRoll LLC

Detta är den offentliga beskrivningen av hur AssuredAuth skyddar de tvåfaktorshemligheter, lösenord och kort som du förvarar i den. Den är skriven så att en säkerhetsmedveten läsare kan kontrollera alla påståenden mot appen och mot de publicerade testvektorerna (tillgängliga för alla granskare på begäran på hello@assuredauth.com). Den säger vad som är sant och inget mer: ingenting här påstår sig vara oåtkomligt, och ingenting utlovas i procent.

Kortversionen: valvet finns på ett ställe, din telefon. Varje värde i det är krypterat med en nyckel som telefonens säkerhetshårdvara lagrar och inte kan exportera. Vi kör ingen valvserver, lagrar ingen kopia och lagrar ingen nyckel. En säkerhetskopia lämnar telefonen först efter att den har krypterats under ett lösenord som aldrig lagras någonstans.

Rapportera ett problem: hello@assuredauth.com. Se "Rapportera en svaghet" i slutet.

1. Vad är krypterat, med vad

DataPå telefonenNyckel
Tvåfaktorshemligheter (TOTP/HOTP/Steam-frön) På telefonenNyckelring (iOS) / Android Keystore-stödd butik NyckelPlattformens hårdvarubundna nyckel; databasraden innehåller endast en referens (secretRef), aldrig fröet
Lösenord (lösenordets värde, anteckningar) På telefonenFörseglad rad: AES-256-GCM, en slumpmässig 96-bitars nonce per värde NyckelEn slumpmässig 256-bitars datanyckel, som i sin tur är omslagen av hårdvarunyckeln i §2
Kort (nummer, utgångsdatum, namn på kort, CVC) På telefonenSamma sigill som lösenord; CVC-koden är valfri och lagras endast om du anger den NyckelSamma datanyckel
Metadata (tjänstnamn, användarnamn, ikoner, sorteringsordning) På telefonenAppens databas (SwiftData / Room) NyckelSkyddas av operativsystemets filkryptering; behandlas som icke-hemlig
Säkerhetskopieringsfil (.authbackup) På telefonenVar du än placerar det: Filer, iCloud Drive, Google Drive appDataFolder, ett delningsark NyckelEn nyckel som härleds från ditt lösenord (§3). Apple och Google får den förseglade filen och inget annat.
Följeslagare för Watch/Wear På telefonenKlockans egen nyckelring / EncryptedSharedPreferences NyckelKlockplattformens nycklar; överförda via plattformens kanal för parade enheter
Trafik för skrivbordstillägg (engångskoder på begäran) På telefonenInte lagrat; vidarebefordras som end-to-end-krypterade kuvert NyckelEtt X25519-nyckelpar per parning, privat nyckel i nyckelringen/nyckellagret; reläet ser endast chiffertext

Diagnostik har ingen metod som accepterar en hemlighet. Ingen analyshändelse bär ett valvfält. Inget värde från valvet skrivs någonsin till en logg, i någon version.

2. Var nycklarna finns, på varje plattform

iOS. Datanyckeln är inkapslad i en nyckel som genereras inuti den säkra enklaven (kSecAttrTokenIDSecureEnclave) med åtkomstkontrollen .privateKeyUsage + .userPresence, accessibility …ThisDeviceOnly, i appens delade nyckelringsåtkomstgrupp så att AutoFill-tillägget kan använda samma nyckel. Den privata nyckeln kan inte läsas ut från enklaven av appen, av en säkerhetskopia eller av en felsökare; enklaven samtycker bara till att använda den efter att användaren är närvarande (Face ID, Touch ID eller enhetens lösenord). ThisDeviceOnly innebär att en iCloud- eller iTunes-säkerhetskopia av telefonen inte innehåller nyckeln; en återställd telefon börjar med ett tomt valv och frågar efter din säkerhetskopia och lösenordsfras. En telefon utan lösenord kan inte skapa en .userPresence-nyckel (Enclave vägrar att skapa en), och simulatorn tar samma väg av sig själv (dess närvarofråga är en varning som inget test kan svara på): där är datanyckeln en vanlig nyckelringsobjekt endast för enheten – fortfarande borta från varje säkerhetskopia, fortfarande oläslig medan telefonen är låst, men utan en andra fråga – och säkerhetsskärmen säger exakt det och föreslår att man ställer in ett lösenord.

Android. Datanyckeln omsluts av en AndroidKeyStore AES-256-nyckel, genererad i StrongBox när enheten har en (annars TEE), med setUserAuthenticationRequired(true) och en 30-sekunders autentiseringsgiltighet efter att en biometrisk kod eller enhetsautentiseringsuppgifter, setUnlockedDeviceRequired(true) och setInvalidatedByBiometricEnrollment(true) lämnats aktiverade. Den sista flaggan är ärlig snarare än bärande: Android tillämpar den bara på nycklar som kräver en biometrisk kod vid varje användning, så på denna 30-sekundersnyckel med enhetsautentiseringsuppgifterna tillåtna ändras ingenting - det som håller en främlings finger borta är att registrering av en behöver PIN-koden, och att borttagning av skärmlåset ogiltigförklarar nyckeln för gott. Keystore-nycklar kan inte exporteras och är exkluderade från Androids molnsäkerhetskopiering. En domän som en app namnger i sina egna vyer (webDomain) tros endast från en känd webbläsare; från alla andra paket måste den också vara en som systemet har verifierat för det paketet (Digital Asset Links), eftersom alla appar kan göra anspråk på vilken domän som helst.

Vad detta innebär för en stulen databasfil. SQLite-filen och de förseglade raderna är chiffertext. Nyckeln som öppnar dem finns i säkerhetshårdvaran på telefonen som filen kommer ifrån och kan inte kopieras med filen. Det finns inget att gissa offline: datanyckeln är slumpmässig och härledd från något en person valt.

3. Säkerhetskopieringsfilen

Säkerhetskopior är det enda som lämnar telefonen, så de är i princip den enda platsen där en offline-attack är möjlig. Designen gör den attacken dyr och ger den så lite att arbeta med som möjligt:

Filen är JSON och läsbar i vilken textredigerare som helst; endast chiffertext är ogenomskinlig. Någon som hittar filen om fem år, utan appen, kan se exakt hur den förseglades och öppna den med OpenSSL eller något Argon2-bibliotek.

Format v1 (levereras i 1.0, förblir läsbart)

{
  "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>"
}
StegByte
keyPBKDF2-HMAC-SHA256(passphrase as UTF-8, salt, 600000 rounds, 32 bytes)
aadUTF-8("authbackup:1:600000:") ‖ salt (råa saltbytes, inte base64)
ciphertext, tagAES-256-GCM(key, nonce, plaintext, aad); tagg 16 byte, lagras separat
plaintextUTF-8 JSON, nycklar sorterade: {"accounts":[…],"exportedAt":"…Z","passwords":[…],"version":1}

Kompatibilitetsinformation: Android 1.0 skrev en variant av v1 — kdf med gemener, ingen taggnyckel (16-byte-taggen som läggs till i chiffertexten), ingen ytterligare data. Båda plattformarna fortsätter att läsa dessa filer (när taggen saknas: dela de sista 16 bytena, öppna med tom AAD; jämför kdf utan att skiftlägeskänsligt använda) och båda skriver nu bara layouten ovan.

Format v2 (nuvarande; standard för nya säkerhetskopior)

{
  "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>"
}
StegByte
keyArgon2id(version 0x13, passphrase as UTF-8, salt, m = 65536 KiB, t = 3, p = 1, tagLength 32, no secret, no associated data)
aadUTF-8("authbackup:2:argon2id:65536:3:1:") ‖ salt
ciphertext, tagAES-256-GCM(key, nonce, plaintext, aad); tagg 16 byte, lagras separat
plaintextUTF-8 JSON, nycklar sorterade: {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2}

Argon2id är referensimplementeringen i C (phc-winner-argon2, CC0), som säljs på båda plattformarna. 64 MiB och 3 pass tar ungefär en sekund på en aktuell telefon och gör att varje gissning kostar det minnet och den tiden på all hårdvara – egenskapen som PBKDF2 saknar mot GPU-riggar, och anledningen till att v2 existerar. En läsare ignorerar nycklar den inte känner till, så en v1-läsare med en v2-kropp ser helt enkelt aldrig kort.

Bevis

Tre testvektorfiler (backup v1, backup v2 och Argon2id) genereras av en tredje implementering, oberoende av båda apparna (Nodes OpenSSL för PBKDF2 och AES-GCM, en WebAssembly Argon2id kontrollerad vid genereringstillfället mot referensimplementeringens publicerade svar). Var och en innehåller lösenfrasen, salt, nonce, klartext, härledd nyckel, AAD, förväntad chiffertext och tagg, och den kompletta filen. Enhetstesterna på iOS och Android läser samma filer och bekräftar samma byte – så en säkerhetskopia som är förseglad på en plattform är bevisad, inte antas, att öppnas på den andra, och en överensstämmelse mellan alla tre är inte två kopior av samma misstag. Ett tillhörande verktyg öppnar en fil som en telefon faktiskt skrev med samma tredje implementering och kontrollerar rubriken mot reglerna ovan (exakt formatets nycklar, så ingen ledtråd eller namn kan finnas; 16-byte salt, 12-byte nonce, 16-byte tagg lagrad separat; version 2 på exakt 64 MiB / 3 / 1; fel lösenfras vägrades); den automatiserade iOS-körningen skriver en fil på simulatorn och öppnar den på det sättet, och söker i simulatorns appbehållare, appgruppsbehållare och nyckelringsdatabas efter varje seedat lösenord och kortnummer som UTF-8 och UTF-16 (0 träffar).

4. Hotmodell

SituationVad de harVad de får
Borttappad eller stulen telefon, låst Vad de harEnheten, databasfilen, de förseglade raderna Vad de fårKrypterad text. Nyckeln finns i Secure Enclave/StrongBox och släpps först efter att enheten har låsts plus en ny biometrisk kod eller lösenord. Om du fjärraddrar telefonen (Hitta min/Hitta min enhet) förstörs nyckelmaterialet med den.
Stulen säkerhetskopia Vad de har.authbackup-filen från ett molnkonto, en e-post, en bärbar dator Vad de fårEn AES-256-GCM-kropp under en nyckel härledd från en lösenfras på minst 12 tecken, med ett salt per fil och Argon2id vid 64 MiB × 3 passerar (v2) eller PBKDF2 vid 600 000 rundor (v1). Ingen ledtråd, inget användarnamn, ingen kontolista i klartext. Varje gissning kostar hela härledningen; det finns ingen genväg. En stark lösenfras är hela försvaret här, och appen säger det på arket.
Stulen enhet med upplåst skärm Vad de harEn telefon i handen, olåst Vad de fårKodlistan. Valvet (lösenord, kort) finns bakom applåset och låses igen med timern för automatisk låsning (omedelbart / 1 min / 5 min); ett dekrypterat värde finns bara i minnet medan skärmen visar det. Autofyllning och export i klartext ber om en ny biometrisk data även när appen är öppen. Aktivera applås med "Omedelbart" om det är det fall du oroar dig för.
Skadlig app på samma telefon Vad de harEn annan apps sandlåda, urklipp, tillgänglighets- eller överlagringsknep Vad de fårDen kan inte läsa våra filer (plattformsandlåda) eller använda vår nyckel (nyckeln är bunden till vår signeringsidentitet och till användarens närvaro). Kopior tas bort från urklipp efter 30 sekunder; på Android flaggas kopian som känslig och exkluderas från urklippshistoriken. Vault-skärmarna är inställda på FLAG_SECURE på Android (inga skärmdumpar, ingen skärminspelning, tomt i växlaren); iOS tömmer växlarens miniatyrbild. Autofyll på Android visas endast för appar som systemet har verifierat mot den sparade domänen (Digitala tillgångslänkar), så en liknande app erbjuds inte ditt lösenord.
Nätfiskesida Vad de harEn webbplats som ser ut som den du sparade Vad de fårIngenting fylls i. Matchning sker via registrerbar domän (offentlig suffixlista, medföljer och uppdateras med appen): login.example.com och example.com matchar, example.com.evil.net och examp1e.com gör det inte. Webbläsaren i appen matchar på samma sätt och fyller bara i den ram som frågade, kontrollerad igen mot den ramens eget ursprung vid ifyllningstillfället; en värd utan egen registrerbar domän – en IP-adress, ett rent namn på det lokala nätverket – matchar exakt och inget lösare. iOS AutoFill lägger till Apples kontroll av associerade domäner. Ett lösenord som du måste klistra in för hand i en kopia är fortfarande en risk; appen kan inte ta bort det, bara undvika att hjälpa till.
Våra egna servrar Vad de har— Vad de fårDet finns ingen valvserver. AssuredAuth har inga konton, ingen inloggning och ingen kopia av ditt valv, så det finns inget som tillhör dig på vår sida som kan stjälas och knäckas. Två saker körs på serversidan, och ingen av dem berör valvet: en reläpostlåda för skrivbordstillägget, som lagrar end-to-end-krypterade kuvert (engångskoder, raderas när de läses; reläet har aldrig en nyckel), och den valfria privata anslutningens exitservrar, som transporterar trafik och inte för åtkomstloggar.
En kallelse eller en begäran från regeringen Vad de harRättslig process riktad mot oss Vad de fårIngenting att lämna över: vi har inget valv, ingen nyckel, ingen lösenfras och ingen säkerhetskopia. Vi kan tvingas att säga det; vi kan inte tvingas att producera det som inte existerar.

5. Urklipp, skärmdumpar och minne

6. Autofyllning: vad som fylls i och vad som inte gör det

VarLösenordKort
iOS: Safari och appar (tillägget Autofyll) LösenordJa, efter ett nytt Face ID / Touch ID / lösenord i tillägget (LAContext), och endast för den registrerbara domänen som posten sparades för, med Apples kontroll av associerade domäner för appar. KortNej. Autofyllning av kort i Safari är enbart från Apple; kortskärmen säger "Fyller i AssuredAuth-webbläsaren och med kopia" och lovar inget annat.
Android: appar och Chrome (AutofillService) LösenordJa, autentisering per dataset: systemet visar BiometricPrompt före ifyllningen; apppaketet matchas endast när Digital Asset Links kopplar det till den sparade domänen. KortJa, tipsen för creditCardNumber, creditCardExpiration* och creditCardSecurityCode, samma biometriska grind
Webbläsaren AssuredAuth (båda plattformarna) LösenordJa, via registrerbar domän — en värd utan exakta matchningar — in i den frågade ramen, biometriskt före ifyllningen KortJa, genom fältdetektering, biometriskt före ifyllning
Kopiera knappar LösenordBakom applåset, 30-sekunders urklipp KortNummer, utgångsdatum, CVC (samma regler)

Ingenting fylls på en värd som liknar en annan. Ingenting fylls utan biometri.

7. Det som aldrig händer

Ingen valvserver. Inga analyser som innehåller ett valvfält. Ingen export i klartext utan ett bekräftelseblad och en ny biometrisk data. Inget SDK från tredje part laddat på en valvskärm. Ingen skärmdump av en valvskärm. Ingen lösenfrasledtråd. Ingen loggning av värden, i någon version.

8. Vad vi inte kan skydda oss mot

En lösenfras som är svag nog att gissa. En telefon vars operativsystem är komprometterat i roten (en jailbreakad eller rootad enhet kan ljuga för appen om allt ovan). En person som blir iakttagen medan den skriver. Skadlig programvara på skrivbordet som du klistrar in i. Vi säger detta så att listan ovan ska läsas för vad den är: de saker en design kan ta bort, tas bort.

9. Granskningsstatus

Denna design har enhetstestats mot publicerade kända svar på båda plattformarna och mot sina egna plattformsoberoende vektorer. En extern granskning finns på ägarens lista innan valvet annonseras i butikslistan; tills det har skett kommer det att anges här i detta dokument.

10. Var saker körs

Ingenting av valvet lämnar telefonen, men några saker runtomkring körs på andra människors maskiner. Detta är listan, och vad var och en innehåller; själva dataflödena beskrivs i integritetspolicyn på https://assuredauth.com/privacy.

Varje rad innehåller vad som står på respektive rad och inget från valvet. Listan ändras när produkten gör det, och det här avsnittet ändras med den.

Rapportera en svaghet

Om du tror att du har hittat en svaghet i något som beskrivs här, skriv till hello@assuredauth.com med ämnesraden "Säkerhet". Vänligen ange plattform, appversion och stegen; ett bevis som använder dina egna data räcker, och vi ber dig att inte testa mot andras. Vi erbjuder inte en PGP-nyckel; om en rapport inte ska skickas via vanlig e-post, säg det i ett första meddelande så ordnar vi ett annat sätt.

Vad vi lovar i gengäld: vi bekräftar inom tre arbetsdagar, håller dig informerad medan vi arbetar med det, korrigerar det som är sant innan något publiceras och anger att du är med i referensen om du vill bli med i referensen. Vi kommer inte att vidta rättsliga åtgärder mot forskning som gjorts i god tro inom ramen nedan.

Ingår i: iOS- och Android-apparna, klockapparna, skrivbordstillägget, assuredauth.com och dess API. Utanför: App Store och Google Play själva, leverantörerna som anges ovan, social manipulation av vem som helst och överbelastning av tjänster.

Det finns ingen belöning för tillfället. En anmälan besvaras med en lagning och ett tack, inte med pengar.