Personvern og kryptering
Disse ordene brukes løst i appbeskrivelser, og forskjellene mellom dem er nøyaktig der verdien ligger. Skjult er ikke låst. Låst er ikke kryptert. Og en nøkkel noen andre holder er ikke egentlig din.
-
ChaCha20-Poly1305
-
En moderne krypteringsalgoritme som både skjuler data og oppdager manipulering av dem. Rask på telefoner, som ikke alltid har maskinvareakselerasjon for det eldre alternativet.
ChaCha20 gjør krypteringen; Poly1305 produserer en tag som bekrefter at dataene ikke er endret. Sammen er de det som kalles autentisert kryptering — dekoding feiler høylytt på en endret fil heller enn å produsere plausibel søppel.
Det er den samme konstruksjonen brukt i TLS og i moderne sikker meldingsutveksling. På maskinvare uten AES-akselerasjon er den merkbart raskere enn AES, som er hvorfor telefoner har en tendens til å foretrekke den.
-
Nøkkelinnpakning
konvoluttkryptering -
Å kryptere filene med én nøkkel, og deretter kryptere den nøkkelen separat med hver inngang. Å endre en passkode pakker inn en liten nøkkel på nytt heller enn å kryptere alt på nytt.
Filer krypteres én gang, med en nøkkel generert på enheten. Den nøkkelen pakkes deretter inn — krypteres — av passkoden, og pakkes inn igjen av gjenopprettingskoden. To konvolutter, én nøkkel inni hver.
Konsekvensene er alle praktiske. En passkodeendring omskriver noen hundre bytes i stedet for hundre gigabyte. Biometrisk opplåsing er en annen innpakket kopi heller enn en annen sikkerhetsmodell. Og å miste hver wrapper mister nøkkelen, fordi nøkkelen finnes ingen andre steder.
Se også: GjenopprettingskodeChaCha20-Poly1305
-
Gjenopprettingskode
-
En engangsstreng som kan pakke opp hovednøkkelen når passkoden er glemt. Ingen kan utstede den på nytt, fordi ingen andre noensinne hadde den — inkludert dem som skrev appen.
Den vises én gang, ved oppsett, og den er den andre av de to dørene. Nedskrevet og holdt et annet sted enn enheten, gjør den en glemt passkode om til en ulempe.
Hvis passkoden glemmes og gjenopprettingskoden mistes, kan filene ikke dekrypteres av noen. Det er ikke en supportpolicy man kan diskutere; det er hva det betyr å ikke ha noen kopi av nøkkelen. Lagre den like forsiktig som filene fortjener.
Se også: NøkkelinnpakningZero-knowledge
-
Lokkehvelv
plausibel deniability -
En andre passkode som åpner et annet, harmløst hvelv. Noen som tvinges til å låse opp appen kan, og det som åpnes er ikke det de lette etter.
Begge passkodene er ekte og begge åpner et ekte hvelv. Ingenting på skjermen indikerer at et annet finnes, og appen kan ikke spørres hvilket den viser.
Det finnes for situasjonen der å nekte å låse opp ikke er et alternativ — en grense, et krav, noen som står over deg. Kryptering alene hjelper ikke der, fordi problemet ikke er nøkkelen, det er å bli tvunget til å bruke den.
-
Nøkkelring
-
Systemets beskyttede lager for små hemmeligheter, støttet av enhetens sikkerhetsmaskinvare. Det er der nøkler og tokens hører hjemme, og der ingenting stort bør gå.
Elementer i den kan bære betingelser: bare lesbare når enheten er ulåst, bare på denne enheten, bare etter biometrisk eller passkodebekreftelse. De betingelsene håndheves av maskinvare heller enn av appen som spør høflig.
Den lagrer hemmeligheter, ikke data. Nøkler, tokens og innpakket materiale går dit; de krypterte filene selv lever på disken, der størrelse ikke er et problem.
-
I hvile vs under overføring
-
Kryptert i hvile betyr uleselig på disken. Kryptert under overføring betyr uleselig på nettverket. De er separate beskyttelser, og et produkt kan ærlig hevde én mens det ikke gjør den andre.
HTTPS er kryptering under overføring: trygt for alle som ser på nettverket, og fullt lesbart for serveren i den andre enden når det ankommer. Kryptering i hvile handler om den lagrede kopien, som er det som betyr noe hvis en enhet mistes eller en disk avbildes.
Å lese et personvernkrav nøye betyr vanligvis å finne ut hvilken av de to det handler om. «Dataene dine er kryptert» uten noen av ordene festet er en setning som er valgt for ikke å si.
Se også: ChaCha20-Poly1305Zero-knowledge
-
Zero-knowledge
-
Et design der operatøren ikke kan lese det den lagrer, fordi nøklene aldri forlater brukerens enheter. Testen er enkel: kan de tilbakestille passordet ditt og fortsatt gi deg dataene dine?
Hvis en tjeneste kan gjenopprette tilgang etter at du glemmer alt, holder den noe som kan låse opp dataene dine — som betyr at den kan tvinges til å bruke det, og at alle som bryter seg inn i tjenesten arver samme evne.
Byttehandelen er ekte og bør sies klart heller enn selges som ren fordel: ekte zero-knowledge betyr genuint å miste tilgang når den siste nøkkelen er tapt. Det finnes ingen tredje mulighet der operatøren kan redde deg men ingen andre kan.
-
Biometri
Face ID, Touch ID -
Enheten, ikke appen, bekrefter at det er deg; appen får vite ja eller nei. Ingen fingeravtrykks- eller ansiktsdata når noensinne en app, og ingen av dem er et passord.
Biometrisk opplåsing er en bekvemmelighet pakket rundt en hemmelighet, ikke en erstatning for én. Det den beskytter er en lagret nøkkel, som er hvorfor en passkode alltid finnes bak den — biometrien kan feile, og fallbacken må være noe du vet.
Sammenligningen skjer inne i dedikert maskinvare og malene forlater den aldri. En app som tilbyr Face ID stiller systemet et spørsmål, ikke samler inn noe.
Se også: NøkkelringNøkkelinnpakning
-
Anonym analyse
-
Å telle hendelser uten å registrere hvem som gjorde dem. Verdien av påstanden avhenger helt av hva som er festet til hver hendelse — og filnavn, stier og URL-er er der slike løfter vanligvis bryter.
Å vite at en skjerm ble åpnet er et tall. Å vite hvilken fil som ble spilt er en beskrivelse av en person. Linjen mellom de to er ikke ordet «anonym»; det er hvilke felt hendelsen bærer.
En påstand verdt å stole på sier hva som *ikke* sendes like spesifikt som hva som sendes: ingen filnavn, ingen stier, ingen URL-er, ingen påloggingsdetaljer, ingen identifikator som overlever på tvers av økter — og tilbyr en måte å slå hele greia av.
Se også: I hvile vs under overføring