Kan en betalt VPN autorisere økter uten kontoen din?
Tokens som ikke kan kobles sammen, kan skille berettigelsessjekken fra selve økten. Det som betyr noe, er utformingen av utstedelse og innløsning, ikke etiketten på innloggingen.
Det å betale for en tunnel behøver ikke bety at betalingsidentiteten vises på hver tilkobling. Et design kan sjekke berettigelsen én gang, gi kunden kryptografiske tokens, og la gatewayen godta et token senere uten å se kontoen bak. Hvorvidt det faktisk skjuler noe, avhenger av valgene for utstedelse og innløsning, så behandle det som en spesifikasjonsøvelse med fire deler i stedet for en innstilling du slår på.
Del kjøpssteget fra sesjonssteget
Privacy Pass-arkitekturen i RFC 9576 gir ordforrådet: en klient, en attestør, en utsteder og en opprinnelse. Klienten beviser en egenskap for utstederen og mottar tokens; senere viser den ett til opprinnelsen, som bestemmer om den vil betjene det. Anvendt på en VPN kan egenskapen som attesteres, være én enkelt tilgangsenhet.
Faktureringen ser fortsatt det dens egen prosess trenger, og ingen hevder noe annet. Det smalere målet er at den senere innløsningen ikke kan spores tilbake til kjøpet som skapte tokenet. Det er en konkret, testbar egenskap, og den er verdt å skrive ned.
En streng som ser tilfeldig ut, gir ikke dette. Dersom utstederen lagrer verdien sammen med en kundepost og gatewayen kan spørre etter den koblingen, er de to interaksjonene forbundet via database i stedet for kryptografi. Konstruksjonen må gjøre utstederen ute av stand til å svare på spørsmålet, og utplasseringen må forhindre at utstederen og gatewayen slår sammen oversiktene sine.
Avgjør hva ett token autoriserer
«Ett token kjøper tilgang» sier nesten ingenting i praksis. Er enheten én tilkobling, en tidskvote eller et volum? Kan en klient som mistet svaret, fortsette med samme tildeling? Hva skjer når en enhet kobler til igjen under en nettverksendring? Disse svarene avgjør om designet er brukbart, og hvert av dem har en personvernkonsekvens.
| Reuse rule | What it buys | What it leaks |
|---|---|---|
| Single use per connection | Strongest unlinkability between sessions | Frequent reissuance, more purchase-to-use timing pairs |
| Bounded time window | Fewer tokens, reconnects work | Activity inside the window is linkable |
| Long-lived grant | Operationally simple | Behaves like an account reference with extra steps |
Velg ett bevisst og skriv feiloppførselen ved siden av. En klient som prøver igjen med en ny rettighet etter en tidsavbrudd, bruker nok en enhet, noe som er både en overraskelse på regningen og et personvernsignal.
Skriv retningslinjene for gjenbruk og tilbakekalling
Tilbakekalling er der anonyme design vanligvis bryter sitt eget løfte. Å avslutte et abonnement og å ugyldiggjøre allerede utstedte tokens er forskjellige operasjoner, og en gateway som stille gjør et kontooppslag for å avgjøre, er ikke lenger anonym på det punktet.
Velg en utløpstid, en utstedelsesgrense og en tilbakekallingshistorie som passer sammen. Sjekk deretter gatewayens egne registre for felt som gjeninnfører koblingen du fjernet.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Det søket lister opp loggfiler som inneholder token- eller kontofelt, og det er det første stedet et grundig design lekker i praksis. En sesjonspost som lagrer tokenverdien ved siden av en kontoidentifikator, undergraver hele konstruksjonen, og den kommer vanligvis inn via en feilsøkingsendring ingen har sett tilbake på.
Definer også hva gatewayen beholder etter at en sesjon er over. Varighet, byte og endepunkt er nyttige for drift, og hvert av dem er en brikke en observatør gjerne vil ha. Hold oppbevaringstiden kort og feltlisten kort, og gjennomgå begge når en feilsøkingsendring legger til en kolonne. Ingen legger merke til et nytt loggfelt før det har vært der i et år.
Formuler påstanden, og deretter observasjonene som er igjen
Skriv personvernpåstanden i én setning med forutsetningene: hvilken part som må være ute av stand til å knytte hvilke kontekster, og hva som skjer hvis utstederen og gatewayen sammenligner notater. Et design som overlever den setningen, kan gjennomgås; et som bare beskrives som «null kunnskap», kan ikke.
List deretter opp det som forblir synlig uansett. Kildeadresser, tilkoblingstider, pakkestørrelser og det enkle faktum at et kjøp skjedde like før den eneste nye tilkoblingen dukket opp, er alt sammen utenfor kryptografien. En enkelt kunde som kjøper én enhet og kobler til én gang, kan kobles sammen bare ved hjelp av tidspunkt, og ingen token-konstruksjon endrer det.
Det ærlige resultatet er en smalere kobling mellom konto og bruk, ikke en usynlig sesjon. Det er fortsatt verdt å bygge, så lenge dokumentasjonen sier det og driftsregistrene stemmer med påstanden.