Sådan fungerer Nets' setup til håndtering af digitale kvitteringer

Nets kører kortnummeret gennem et envejs hash-algoritme i terminalen i forbindelse med en tjeneste fra virksomheden, hvor kvitteringer kan tilgås digitalt hos tredjeparter.

Privacy-interesserede har den senere tid diskuteret, blandt andet her på Version2 og på Twitter, hvordan systemer til lagring af digitale kvitteringer egentlig fungerer. Version2 kan her redegøre for teknologien. Noget af det foregår i kraft af en tjeneste fra virksomheden bag en væsentlig del den danske infrastruktur for betalingskort, Nets.

I størstedelen af de terminaler, Nets understøtter, ligger der et sikkerhedsmodul kaldet Purchase Security Application Module (PSAM). Der er tale om en portabel chip, som svarer til simkortet i en mobiltelefon.

PSAM-modulet kan indeholde det, der kaldes en envejs hash-algoritme. Det vil sige en algoritme, der i udgangspunktet danner en entydig output-værdi ud fra en input-værdi. I dette tilfælde er inputværdien kortnummeret. På den måde er det altså muligt at skjule det oprindelige kortnummer og samtidig generere en entydig nøgle, der relaterer sig til kortnummeret.

»Kortnummeret er følsomme data, så det må ikke florere rundt i kasseterminaler eller andre systemer i klar tekst. Så derfor har vi lavet denne envejsfunktion, hvor tanken er, at kortnummeret ikke kan findes den anden vej rundt ud fra hash-værdien,« forklarer it-ekspert inden for digitale kvitteringer hos Nets Kim Dons Laursen.

I det konkrete tilfælde er der tale om hash-algoritmen SHA256, der er blandt kravene for at leve op til Payment Card Industry Data Security Standard. En sikkerhedsstandard for organisationer, der håndterer betalingskort.

»Vi leverer hash-værdien, og de kan benyttes som pegepind. Den bliver dels genereret ude i terminalen, og den bliver også genereret, når man opretter sig som bruger hos en udbyder af digitale kvitteringer. Det er den måde, man bliver genkendt i forhold til at kunne tilgå sine kvitteringer efterfølgende,« siger Kim Dons Laursen.

Når kunden kører kortet igennem betalingsterminalen, kan forretningen koble hash-værdien med kundens kvitteringsdata. Og når brugeren så opretter sig hos en udbyder af digitale kvitteringer og indtaster et kortnummer, bliver kortnummeret kørt gennem samme hash-algoritme.

Herefter kan den afledte kortnummer-værdi på kvitteringsdata, som butikkerne har opsamlet, holdes op mod den unikke værdi - ligeledes afledt af kortnummeret - som bliver genereret, når kortet bliver tilføjet på hjemmesiden for udbyderen af digitale kvitteringer.

Og kunden kan nu se sine kvitteringer. For at forhindre, at alle med kendskab til den kendte hash-algoritme kan koble de følsomme kort-data til kvitteringer i butikkernes backend, så er de enkelte udbyderes hash-algoritmer udstyret med et unikt salt. Det vil sige en parameter, der sikrer, at to forskelligt saltede SHA256-algoritmer ikke genererer samme output ved samme input.

»Saltet er en hemmelig talrække, som hver tjenesteudbyder (af digitale kvitteringer, red.) anvender,« siger Kim Dons Laursen.

Saltet bliver udskiftet med jævne mellemrum for at gøre det vanskeligt at gennemføre et brute force-angreb, forklarer Kim Dons Laursen. Altså så uvedkommende ikke skal kunne gætte sig til hash-værdierne bag et specifikt kortnummer ved at forsøge et tilstrækkeligt antal gange.

Kim Dons Laursen anslår, at en håndfuld virksomheder anvender Nets' tjeneste, der i øvrigt har eksisteret i ca. to år.

Flere løsninger

Hvordan koblingen sker mellem kvitteringsdata, der bliver indsamlet ude i butikkerne og så hos udbydere af digitale kvitteringsløsninger, lader til at være forskellig.

Formand for IT-Politisk Forening Jesper Lund har tidligere kritiseret, blandt andet på Twitter og her på Version2, at eKvittering, der nu er gået konkurs, tilsyneladende har fået tilsendt kvitteringsdata ved betalinger, uanset om kort-brugeren har været tilmeldt tjenesten eller ej.

Læs også: Privacy-bekymring over privat virksomheds indsamling af kvitteringsdata

Det var eKvitterings feature, hvor brugere tilsyneladende var i stand til at se historiske kvitteringer fra før, brugerne oprettede sig på tjenesten, der gjorde Jesper Lund mistænksom i forhold til den del.

Version2 har flere gange forgæves forsøgt at komme i kontakt med de to stiftere bag eKvittering.

Jesper Lund har i privacy'ens navn også været i kontakt med Storebox (tidl. kvittering.dk). Virksomheden har oplyst til Jesper Lund, at kvitteringsdata først bliver sendt fra forretningen til Storebox, når det er verificeret, at kunden i forretningen også er oprettet som bruger hos Storebox. Det foregår ved, at butikken sender et token til Storebox, som på den baggrund validerer, om kunden er bruger, og hvis det er tilfældet, bliver kvitteringsdata også sendt.

Version2 har været i kontakt med medstifter af Storebox Jacob Aisen, der med henvisning til sikkerhed ikke umiddelbart ønsker at gå i nærmere tekniske detaljer om, hvordan Storebox' tjeneste fungerer. Han oplyser dog, at virksomheden anvender flere forskellige løsninger i forbindelse med tjenesten, herunder løsninger som Nets tilbyder.

Danske Bank, Storebox og andre kunne i juni i en pressemeddelelse under overskriften 'Slut med krøllede kvitteringer i skuffer og skabe' annoncere et partnerskab på Danske Banks udbredte app til mobilbetalinger, MobilePay. Partnerskabet betyder, at Storebox nu er blevet direkte tilgængelig via MobilePay, så Storebox-brugere kan se deres kvitteringer i Danske Banks app, herunder dem der bliver genereret ved køb med Mobile Pay.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jakob Møbjerg Nielsen

og så er det jo ligegyldigt at hver forretning har sit eget salt.

Jeg misforstod vist. Det er kvitteringsudbyderne, der har hvert sit salt, men så vidt jeg forstår på artiklen, så får butikken et usaltet SHA-256 hash af kortnummeret. Jeg er i hvert fald stadig ikke overbevist om sikkerheden i dette. Det kræver en mere klar beskrivelse af løsningen.

Morten Johnstad-Møller

Som Peter Kyllesbeck skriver så giver den variable SALT-værdi nogle problemer. Samme kortnummer giver ikke samme hash-værdi med forskellig SALT - derfor skal man skulle bede kunden om at indtast kortnummer hver gang SALT ændres, for at kunne lave mappingen til nye køb -> dårlig brugeroplevelse (med mindre man gemmer brugerens kortnummer, men det sætter helt nye krav til ens infrastruktur)
Pludselig er det heller ikke trivielt at lave en liste over alle køb, da en kunde vil have forskellige hash-værdier på samme kort over tid.

Dette er helt konkret problemet, der afholder os fra at implementere det hos en stor kæde i dag. Jeg håber, at NETS knækker den også. F.eks. med en end-to-end service som vi kender fra betalingleverandører.

Jakob Møbjerg Nielsen

Jeg havde ikke fantasi til at forestillet mig, at kunderne skulle indtaste kortnummeret flere gange. Nu faldt 25-øren, og jeg tror jeg ved hvordan saltet sikrer løsningen: Både betalingsterminalerne og kvitteringsudbyderen må kende saltet. Ellers kan man ikke holde butikken udenfor, og kortnummeret sikkert... eller hvad?

Gad vide hvorfor man ikke blot krypterer kortnummeret i stedet?

Morten Johnstad-Møller

SHA256(Kortnummer, SALT) -> unik hash-værdi.
Denne værdi beregner terminalen og sender til kvitteringsudbyder som laver samme beregning og kan nu sammenligne de unikke hash-værdier og således de hvilken kort der har foretaget hvilket køb - men uden at kunne se kortnummer. Snedigt.
Ny SALT -> ny hash -> se tideligere kommentar...

Jakob Møbjerg Nielsen

Denne værdi beregner terminalen og sender til kvitteringsudbyder som laver samme beregning

Tak for svar. Så var det bare mig, der ikke havde fantasi nok til at forestille mig så ringe brugervenlighed. :-)

Men igen... hvorfor ikke blot kryptere det, eller måske genere et tilfældigt salt, som sendes med? Hvis det aftalte salt er stort nok, burde der ikke være sikkerhedsmæssige problemer.

Jacob Ipsen

Beskrivelsen Morten kommer med er god nok
PSAM og Modtager kender begge "KEY" som bruger modtager kun denne for at kryptere kort der tilføjes, sammenligning er altid af krypterede kortnumre.
dvs KEY ligger sikret særskildt.

Om data sendes inden kunder oprettes eller ej er op til den enkelte POS Producent.:)

Dog er jeg ikke helt sikker på om der er lavet mulighede for at tjekke om et givent hash er tilmeldt eller ej da dette i sig selv udgør en sikkerheds risiko.

så mit bedste bud er at alle bonner sendes videre for alle salg , og så er det op til modtager at sortere fra, eller gemme...

Jesper Lund

Pludselig er det heller ikke trivielt at lave en liste over alle køb, da en kunde vil have forskellige hash-værdier på samme kort over tid.

Tjenesteudbyder er vel bekendt med hvilke salt-værdier der har været anvendt for de enkelte perioder? Når kortholder kommer med kortnummeret for at gøre brug af en service som tjenesteudbyder tilbyder, kan de pågældende kvitteringer sammenkædes. Men det kan ikke gøres fuldt ud uden hjælp fra kortholder.

Hvad er det for et problem du søger at løse her?

Jeg synes Nets udleverer for mange oplysninger. I forhold til butikkerne bør betaling med kort ikke generere flere oplysninger end betaling med kontanter. Det skaber unødvendige sikkerhedsrisici og det truer vores privatliv. At skifte salt en gang i mellem gør det (lidt) vanskeligere at sammenkæde de enkelte køb (over længere perioder, i hvert fald), så det vil være til skade for sikkerhed og privacy hvis Nets holder op med at skifte salt.

Men helt generelt skulle Nets stoppe med dette datamisbrug. Transaktioner-IDer skal ikke kunne sammenkædes hos butikkerne eller tredjeparter (de nævnte tjenesteudbyder). Men så var Nets-biksen måske ikke 17 mia værd..

Jesper Lund

At skifte salt en gang i mellem gør det (lidt) vanskeligere at sammenkæde de enkelte køb (over længere perioder, i hvert fald), så det vil være til skade for sikkerhed og privacy hvis Nets holder op med at skifte salt.

Antallet at kortnumre er ret begrænset. Alle Visa Dankort starter med 4571, derefter har vi bankens/filialens registeringsnummer (som der er et par hundrede af?), og så er der 8 cifre tilbage. Måske endda færre hvis der er checkcifre i det 16-cifrede kortnummer?

Det må være trivielt at sammenkæde to hashværdier med forskellig salt..

Simon Mikkelsen

Der er en del snak om kortnummeret, men indholdet af kvitteringen er mindst lige så følsomt. Hvis man kører lidt statistik mellem mine kvitteringer og fx Facebook kan man nok godt finde frem til mig (har fx lige fået et barn => køber new born bleer). En tyv vil være best case - folk der ikke kan lide mig vil ikke være sjovt.

Morten Johnstad-Møller
Bjarne Nielsen

Der er en del snak om kortnummeret, men indholdet af kvitteringen er mindst lige så følsomt.

Ikke for betalingskortsselskabet. Og derfor er det ikke sikret.

Men du har helt ret. Jeg har før linket til en artikel om det på Videnskab.dk. Lad mig citere fra den:

9 ud af 10 personer kunne altså identificeres i datasættet ud fra viden om sted og dato for kun 4 handler.

Bjarne Nielsen

Får butikken det hashede kortnummer med salt?

Jeg er ikke sikker på, hvad du mener, og min viden stammer kun fra ovenstående artikel, men jeg vil mene, at svaret er ja.

Det betyder også, at alle betalinger for et kort kan knyttes sammen ved at de alle har samme hash (indtil saltet ændres), på tværs af butikker og til alle tider. Finder jeg i dag en betaling fra 2011, så vil jeg kunne knytte den sammen med alle andre betalinger med det kort fra den periode, hvor saltet var det samme.

Problemet her er ikke, at man bruger en fjollet fremgangsmåde (hvis salt er fornuftigt, så er det faktisk en OK fremgangsmåde), men udelukkende at man genbruger samme nøgleværdi. Det vil også kunne ske selvom id var kommet som ægte tilfældighed.

Hvor stort problemet med 'linkability' er afhænger helt af, hvor tit man skifter saltet. Som tidligere bemærket, så skal man ikke have adgang til mange datapunkterne, som man ved hører sammen, før det er muligt at identificere hvem det tilhører. Og man kan selv komme til at afsløre det, ved at bruge et kunderabatkort bare en gang, eller købe noget med forsikring. Nu er kortets id knyttet til dig, og kan sammenkædes med de basser du købte på vej ind og den håndkøbsmedicin du kom tilbage senere og købte. Lige fra dengang saltet skiftede sidst, og indtil det skifter igen.

Får man snablen i data fra butikker i hver sin ende af landet fra perioden med samme salt, så kan de også kædes sammen. Også selvom saltet er skiftet nok så mange gange siden.

Morten Johnstad-Møller

Snakken har ændret sig lidt fra en snak om hvordan vil om bør vi? To helt forskellige tråde i min bog.

For lige at blande mig lidt i sidste så er ideen at hver butik/aftale med Nets får en unik SALT-værdi, således at køb ikke kan sammenkøres på tværs af virksomheder. Nets har faktisk tænkt ret meget over sikkerheden her - faktisk så meget, at jeg syntes, at det reelt er ubrugeligt til at bygge brugervenlige services på.

Bjarne Nielsen

... det reelt er ubrugeligt til at bygge brugervenlige services på.

Hvis brugervenlighed indebærer Skodaer med faste WiFi password, som står i manualen, og insulinpumper der kan få ændret dosering over nettet, så vil jeg helst være fri. Begge dele er sikkert opstået i bedste mening, og med en god brugeroplevelse som mål.

Jeg er ikke interesseret i nemt at kunne tilgå mine oplysninger, hvis det betyder, at det er mindst lige så nemt for alle mulige andre. Og jeg er ikke interesseret i at blive husket og genkendt, hvis det kan bruges imod mig eller skade mig.

Bjarne Nielsen

En danske dom (ældre dato) siger at kortnummer og udløbs data (vist før CVC) ikke er fortrolige/hemmelige data, da de står på kortet

Uden at kende detaljerne, så er jeg pænt sikker på, at der her er tale om forskellige regelsæt. De regler, som betalingskortudbyderne forlanger overholdt for at ville handle med dig, opfatter dem som data, som skal beskyttes særskilt (jeg tror slet ikke at CVC o.lign. på registreres i nogen form, beskyttet eller ej).

Men det illustrerer meget godt, at der er forskellige interesser på spil.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder