Tokenisering (datasäkerhet)
Tokenisering , när den tillämpas på datasäkerhet, är processen att ersätta ett känsligt dataelement med en icke-känslig motsvarighet, kallad en token , som inte har någon inneboende eller exploateringsbar mening eller värde. Token är en referens (dvs. identifierare) som mappar tillbaka till den känsliga informationen genom ett tokeniseringssystem. Mappningen från originaldata till en token använder metoder som gör tokens omöjliga att vända i avsaknad av tokeniseringssystemet, till exempel genom att använda tokens skapade från slumpmässiga siffror . En enkelriktad kryptografisk funktion används för att konvertera originaldata till tokens, vilket gör det svårt att återskapa originaldata utan att få tillgång till tokeniseringssystemets resurser. För att leverera sådana tjänster upprätthåller systemet en valvdatabas med tokens som är kopplade till motsvarande känsliga data. Att skydda systemvalvet är avgörande för systemet, och förbättrade processer måste införas för att erbjuda databasintegritet och fysisk säkerhet.
Tokeniseringssystemet måste säkras och valideras med bästa säkerhetspraxis som gäller för känslig dataskydd, säker lagring, granskning, autentisering och auktorisering. Tokeniseringssystemet förser databehandlingsapplikationer med auktoritet och gränssnitt för att begära tokens, eller detokenisera tillbaka till känslig data.
Säkerhets- och riskminskningsfördelarna med tokenisering kräver att tokeniseringssystemet är logiskt isolerat och segmenterat från databehandlingssystem och applikationer som tidigare bearbetade eller lagrade känslig data som ersatts av tokens. Endast tokeniseringssystemet kan tokenisera data för att skapa tokens, eller detokenisera tillbaka för att lösa in känslig data under strikta säkerhetskontroller. Tokengenereringsmetoden måste bevisas ha egenskapen att det inte finns några genomförbara medel genom direkta attacker, kryptoanalys , sidokanalanalys, exponering för tokenmappningstabeller eller brute force-tekniker för att vända tokens tillbaka till livedata.
Att ersätta livedata med tokens i system är avsett att minimera exponeringen av känslig data för dessa applikationer, butiker, människor och processer, vilket minskar risken för kompromiss eller oavsiktlig exponering och obehörig åtkomst till känslig data. Applikationer kan fungera med hjälp av tokens istället för livedata, med undantag för ett litet antal betrodda applikationer som uttryckligen tillåts avtokenisera när det är absolut nödvändigt för ett godkänt affärsändamål. Tokeniseringssystem kan drivas internt inom ett säkert isolerat segment av datacentret, eller som en tjänst från en säker tjänsteleverantör.
Tokenisering kan användas för att skydda känsliga uppgifter som till exempel involverar bankkonton , bokslut , medicinska register , kriminalregister , körkort , låneansökningar , aktieaffärer , väljarregistreringar och andra typer av personligt identifierbar information (PII). Tokenisering används ofta vid kreditkortshantering. PCI Council definierar tokenisering som "en process genom vilken det primära kontonumret (PAN) ersätts med ett surrogatvärde som kallas en token. Ett PAN kan kopplas till ett referensnummer genom tokeniseringsprocessen. I det här fallet har handlaren helt enkelt att behålla token och en pålitlig tredje part kontrollerar relationen och innehar PAN. Token kan skapas oberoende av PAN, eller PAN kan användas som en del av datainmatningen till tokeniseringstekniken. Kommunikationen mellan handlaren och tredjepartsleverantören måste vara säker för att förhindra en angripare från att avlyssna för att få PAN och token.
Av-tokenisering är den omvända processen att lösa in en token för dess tillhörande PAN-värde. Säkerheten för en enskild token beror till övervägande del på omöjligheten att bestämma det ursprungliga PAN genom att bara känna till surrogatvärdet". Valet av tokenisering som ett alternativ till andra tekniker som kryptering kommer att bero på olika regulatoriska krav, tolkning och acceptans av respektive revision . eller bedömningsenheter. Detta är utöver alla tekniska, arkitektoniska eller operativa begränsningar som tokenisering medför i praktisk användning.
Begrepp och ursprung
Konceptet med tokenisering, som antagits av branschen idag, har funnits sedan de första valutasystemen dök upp för århundraden sedan som ett sätt att minska risken vid hantering av högvärdiga finansiella instrument genom att ersätta dem med surrogatekvivalenter. I den fysiska världen myntpoletter en lång historia av användning som ersätter det finansiella instrumentet med präglade mynt och sedlar . I nyare historia har tunnelbanepolletter och kasinomarker använts för sina respektive system för att ersätta fysiska valuta- och kontanthanteringsrisker som stöld. Exonumia och scrip är termer som är synonyma med sådana tokens.
I den digitala världen har liknande substitutionstekniker använts sedan 1970-talet som ett sätt att isolera verkliga dataelement från exponering för andra datasystem. I databaser har till exempel surrogatnyckelvärden använts sedan 1976 för att isolera data som är associerade med databasernas interna mekanismer och deras externa motsvarigheter för en mängd olika användningsområden vid databehandling. På senare tid har dessa begrepp utökats för att överväga denna isoleringstaktik för att tillhandahålla en säkerhetsmekanism för dataskyddsändamål.
Inom betalkortsindustrin är tokenisering ett sätt att skydda känsliga kortinnehavares data för att följa branschstandarder och statliga föreskrifter.
2001 skapade TrustCommerce konceptet Tokenization för att skydda känslig betalningsdata för en klient, Classmates.com. Det engagerade Rob Caulfield, grundare av TrustCommerce, eftersom risken för att lagra kortinnehavarens data var för stor om systemen någonsin hackades. TrustCommerce utvecklade TC Citadel®, med vilken kunder kunde referera till en token i stället för kortinnehavarens data och TrustCommerce skulle behandla en betalning för handlarens räkning. Denna faktureringsapplikation gjorde det möjligt för kunder att behandla återkommande betalningar utan att behöva lagra kortinnehavarens betalningsinformation. Tokenisering ersätter det primära kontonumret (PAN) med slumpmässigt genererade tokens. Om den avlyssnas innehåller informationen ingen kortinnehavarinformation, vilket gör den oanvändbar för hackare. PAN kan inte hämtas, även om token och de system som den finns på har äventyrats, inte heller kan token omvändas för att komma fram till PAN.
Tokenisering tillämpades på betalkortsdata av Shift4 Corporation och släpptes till allmänheten under ett branschsäkerhetstoppmöte i Las Vegas, Nevada 2005. Tekniken är avsedd att förhindra stöld av kreditkortsinformation som lagras. Shift4 definierar tokenisering som: "Konceptet att använda en icke-dekrypterbar databit för att representera, genom referens, känslig eller hemlig data. I betalkortsindustrins (PCI) sammanhang används tokens för att referera till kortinnehavarens data som hanteras i ett tokeniseringssystem, en applikation eller en säker anläggning utanför platsen."
För att skydda data under hela dess livscykel kombineras tokenisering ofta med end-to-end-kryptering för att säkra data under överföring till tokeniseringssystemet eller tjänsten, med en token som ersätter den ursprungliga datan vid retur. Till exempel, för att undvika riskerna för att skadlig programvara stjäl data från system med låg förtroende som t.ex. försäljningsställen (POS-system), som i målöverträdelsen från 2013, måste kortinnehavarens datakryptering ske innan kortdata kommer in i POS och inte efter . Kryptering sker inom gränserna för en säkerhetshärdad och validerad kortläsenhet och data förblir krypterad tills den tas emot av bearbetningsvärden, ett tillvägagångssätt som pionjärer av Heartland Payment Systems som ett sätt att säkra betalningsdata från avancerade hot, nu allmänt antagen av industribetalningar förädlingsföretag och teknikföretag. PCI Council har också specificerat end-to-end-kryptering (certifierad punkt-till-punkt-kryptering—P2PE) för olika tjänsteimplementationer i olika PCI Council punkt-till-punkt-kryptering- dokument.
Tokeniseringsprocessen
Tokeniseringsprocessen består av följande steg:
- Applikationen skickar tokeniseringsdata och autentiseringsinformation till tokeniseringssystemet.
- Applikationen skickar tokeniseringsdata och autentiseringsinformation till tokeniseringssystemet. Den stoppas om autentiseringen misslyckas och data levereras till ett händelsehanteringssystem. Som ett resultat kan administratörer upptäcka problem och effektivt hantera systemet. Systemet går vidare till nästa fas om autentiseringen lyckas.
- Genom att använda envägskrypteringstekniker genereras en token och förvaras i ett mycket säkert datavalv.
- Den nya token ges till applikationen för vidare användning.
Tokeniseringssystem delar flera komponenter enligt etablerade standarder.
- Tokengenerering är processen att producera en token med hjälp av vilket sätt som helst, såsom matematiskt reversibla kryptografiska funktioner baserade på starka krypteringsalgoritmer och nyckelhanteringsmekanismer, envägs icke-reversibla kryptografiska funktioner (t.ex. en hashfunktion med starkt, hemligt salt) eller tilldelning via ett slumpmässigt genererat nummer. Random Number Generator-tekniker (RNG) är ofta det bästa valet för att generera tokenvärden.
- Tokenmapping – detta är processen för att tilldela det skapade tokenvärdet till dess ursprungliga värde. För att möjliggöra tillåtna uppslagningar av det ursprungliga värdet med hjälp av token som index måste en säker korsreferensdatabas konstrueras.
- Token Data Store – detta är ett centralt arkiv för Token Mapping-processen som innehåller de ursprungliga värdena såväl som de relaterade tokenvärdena efter Token Generation-processen. På dataservrar måste känsliga data och tokenvärden förvaras säkert i krypterat format.
- Krypterad datalagring – detta är krypteringen av känslig data medan den är under överföring.
- Hantering av kryptografiska nycklar. Starka nyckelhanteringsprocedurer krävs för kryptering av känslig data på Token Data Stores.
Skillnad från kryptering
Tokenisering och "klassisk" kryptering skyddar effektivt data om de implementeras korrekt, och ett datorsäkerhetssystem kan använda båda. Även om de är lika i vissa avseenden, skiljer sig tokenisering och klassisk kryptering i några viktiga aspekter. Båda är kryptografiska datasäkerhetsmetoder och de har i huvudsak samma funktion, men de gör det med olika processer och har olika effekter på den data de skyddar.
Tokenisering är ett icke-matematiskt tillvägagångssätt som ersätter känslig data med icke-känsliga substitut utan att ändra typen eller längden på data. Detta är en viktig skillnad från kryptering eftersom förändringar i datalängd och datatyp kan göra information oläsbar i mellanliggande system som databaser. Tokeniserad data kan fortfarande bearbetas av äldre system vilket gör tokenisering mer flexibel än klassisk kryptering.
I många situationer är krypteringsprocessen en konstant förbrukare av processorkraft, därför behöver ett sådant system betydande utgifter för specialiserad hårdvara och mjukvara.
En annan skillnad är att tokens kräver betydligt mindre beräkningsresurser att bearbeta. Med tokenisering hålls specifik data helt eller delvis synlig för bearbetning och analys medan känslig information hålls dold. Detta gör att tokeniserade data kan behandlas snabbare och minskar belastningen på systemresurserna. Detta kan vara en viktig fördel i system som förlitar sig på hög prestanda.
Jämfört med kryptering minskar tokeniseringstekniker tid, kostnader och administrativa ansträngningar samtidigt som det möjliggör lagarbete och kommunikation.
Typer av tokens
Det finns många sätt som tokens kan klassificeras på, men det finns för närvarande ingen enhetlig klassificering. Tokens kan vara: engångs- eller fleranvändningsbara, kryptografiska eller icke-kryptografiska, reversibla eller irreversibla, autentiserade eller icke-autentiserbara, och olika kombinationer därav.
I betalningssammanhang spelar skillnaden mellan högt och lågt värde tokens en betydande roll.
Högvärdiga tokens (HVT)
HVT fungerar som surrogat för faktiska PAN i betalningstransaktioner och används som ett instrument för att slutföra en betalningstransaktion. För att fungera måste de se ut som faktiska PAN. Flera HVT:er kan mappa tillbaka till ett enda PAN och ett enda fysiskt kreditkort utan att ägaren är medveten om det.
Dessutom kan HVT begränsas till vissa nätverk och/eller handlare medan PAN inte kan.
HVT:er kan också bindas till specifika enheter så att avvikelser mellan tokenanvändning, fysiska enheter och geografiska platser kan flaggas som potentiellt bedrägliga.
Lågvärdestokens (LVT) eller säkerhetstokens
LVT fungerar också som surrogat för faktiska PAN i betalningstransaktioner, men de tjänar ett annat syfte. LVT kan inte användas av sig själva för att slutföra en betalningstransaktion. För att ett LVT ska fungera måste det vara möjligt att matcha det tillbaka till det faktiska PAN det representerar, om än bara på ett hårt kontrollerat sätt. Att använda tokens för att skydda PAN blir ineffektivt om ett tokeniseringssystem bryts, därför är det extremt viktigt att säkra själva tokeniseringssystemet.
Systemdrift, begränsningar och utveckling
Första generationens tokeniseringssystem använder en databas för att kartlägga från livedata för att ersätta tokens och tillbaka. Detta kräver lagring, hantering och kontinuerlig säkerhetskopiering för varje ny transaktion som läggs till tokendatabasen för att undvika dataförlust. Ett annat problem är att säkerställa konsistens mellan datacenter, vilket kräver kontinuerlig synkronisering av tokendatabaser. Betydande konsekvens, tillgänglighet och prestanda avvägningar, enligt CAP-teoremet , är oundvikliga med detta tillvägagångssätt. Denna overhead lägger till komplexitet till transaktionsbehandling i realtid för att undvika dataförlust och för att säkerställa dataintegritet över datacenter, och begränsar även skalan. Att lagra alla känsliga data i en tjänst skapar ett attraktivt mål för attacker och kompromisser, och introducerar integritets- och juridiska risker i sammanställningen av dataintegritet på Internet , särskilt i EU .
En annan begränsning av tokeniseringsteknologier är att mäta säkerhetsnivån för en given lösning genom oberoende validering. Med bristen på standarder är det senare avgörande för att fastställa styrkan av tokenisering som erbjuds när tokens används för regelefterlevnad. PCI Council rekommenderar oberoende granskning och validering av alla påståenden om säkerhet och efterlevnad: "Säljare som överväger användningen av tokenisering bör utföra en grundlig utvärdering och riskanalys för att identifiera och dokumentera de unika egenskaperna hos deras specifika implementering, inklusive all interaktion med betalkortsdata och de särskilda tokeniseringssystemen och -processerna"
Metoden att generera tokens kan också ha begränsningar ur ett säkerhetsperspektiv. Med oro för säkerhet och attacker mot slumptalsgeneratorer , som är ett vanligt val för generering av tokens och tokenmappningstabeller, måste granskning tillämpas för att säkerställa att beprövade och validerade metoder används kontra godtycklig design. Slumptalsgeneratorer har begränsningar vad gäller hastighet, entropi, seedning och bias, och säkerhetsegenskaper måste noggrant analyseras och mätas för att undvika förutsägbarhet och kompromisser.
Med tokeniseringens ökande antagande har nya tokeniseringsteknologiska tillvägagångssätt dykt upp för att ta bort sådana operativa risker och komplexitet och för att möjliggöra ökad skala som är lämpad för nya fall för användning av big data och högpresterande transaktionsbearbetning, särskilt inom finansiella tjänster och banker. Utöver konventionella tokeniseringsmetoder ger Protegrity ytterligare säkerhet genom sitt så kallade "obfuscation layer". Detta skapar en barriär som hindrar inte bara vanliga användare från att komma åt information de inte skulle se utan också privilegierade användare som har åtkomst, till exempel databasadministratörer.
Statslös tokenisering möjliggör slumpmässig mappning av levande dataelement för att ersätta värden utan att behöva en databas samtidigt som tokeniseringens isoleringsegenskaper bibehålls.
November 2014 släppte American Express sin tokentjänst som uppfyller EMV- tokeniseringsstandarden. Andra anmärkningsvärda exempel på tokeniseringsbaserade betalningssystem, enligt EMVCo-standarden, inkluderar Google Wallet , Apple Pay , Samsung Pay , Microsoft Wallet , Fitbit Pay och Garmin Pay . Visa använder tokeniseringstekniker för att tillhandahålla en säker online och mobil shopping.
Genom att använda blockchain, i motsats till att förlita sig på betrodda tredje parter, är det möjligt att köra mycket tillgängliga, manipuleringssäkra databaser för transaktioner. Med hjälp av blockchain är tokenisering processen att omvandla värdet av en materiell eller immateriell tillgång till en token som kan bytas ut på nätverket.
Detta möjliggör tokenisering av konventionella finansiella tillgångar, till exempel genom att omvandla rättigheter till en digital token som backas upp av tillgången själv med hjälp av blockchain-teknik. Utöver det möjliggör tokenisering enkel och effektiv uppdelning och hantering av data över flera användare. Individuella tokens skapade genom tokenisering kan användas för att dela ägande och delvis sälja en tillgång. Följaktligen kan endast enheter med lämplig token komma åt data.
Många blockchain-företag stöder tillgångstokenisering. 2019 eToro Firmo och bytte namn till eToroX. Genom sin Token Management Suite, som backas upp av USD-kopplade stablecoins, möjliggör eToroX tillgångstokenisering.
Tokeniseringen av eget kapital underlättas av STOKR, en plattform som länkar investerare med små och medelstora företag. Tokens utgivna via STOKR-plattformen är juridiskt erkända som överlåtbara värdepapper enligt Europeiska unionens kapitalmarknadsbestämmelser.
Breakers möjliggör tokenisering av immateriella rättigheter, vilket gör att innehållsskapare kan utfärda sina egna digitala tokens. Tokens kan distribueras till en mängd olika projektdeltagare. Utan mellanhänder eller styrande organ kan innehållsskapare integrera funktioner för belöningsdelning i token.
Applikation på alternativa betalningssystem
Att bygga ett alternativt betalningssystem kräver att ett antal enheter arbetar tillsammans för att kunna leverera närfältskommunikation (NFC) eller andra teknikbaserade betaltjänster till slutanvändarna. En av frågorna är interoperabiliteten mellan aktörerna och för att lösa denna fråga föreslås rollen som Trusted Service Manager (TSM) för att upprätta en teknisk länk mellan mobilnätsoperatörer (MNO) och leverantörer av tjänster, så att dessa enheter kan arbeta tillsammans . Tokenisering kan spela en roll vid förmedling av sådana tjänster.
Tokenisering som säkerhetsstrategi ligger i möjligheten att ersätta ett verkligt kortnummer med ett surrogat (målborttagning) och de efterföljande begränsningarna som sätts på surrogatkortnumret (riskminskning). Om surrogatvärdet kan användas på ett obegränsat sätt eller till och med på ett brett tillämpligt sätt, får tokenvärdet lika mycket värde som det verkliga kreditkortsnumret. I dessa fall kan token vara säkrad av en andra dynamisk token som är unik för varje transaktion och även kopplad till ett specifikt betalkort. Exempel på dynamiska, transaktionsspecifika tokens inkluderar kryptogram som används i EMV-specifikationen.
Applikation till PCI DSS-standarder
Payment Card Industry Data Security Standard , en branschövergripande uppsättning riktlinjer som måste uppfyllas av alla organisationer som lagrar, bearbetar eller överför kortinnehavardata, kräver att kreditkortsdata måste skyddas när de lagras. Tokenisering, som tillämpas på betalkortsdata, implementeras ofta för att uppfylla detta mandat, och ersätter kreditkorts- och ACH-nummer i vissa system med ett slumpmässigt värde eller teckensträng. Tokens kan formateras på en mängd olika sätt. Vissa tokentjänsteleverantörer eller tokeniseringsprodukter genererar surrogatvärdena på ett sådant sätt att de matchar formatet för den ursprungliga känsliga informationen. När det gäller betalkortsdata kan en token ha samma längd som ett primärt kontonummer ( bankkortsnummer ) och innehålla delar av originaldata som de fyra sista siffrorna i kortnumret. När en begäran om auktorisering av betalkort görs för att verifiera en transaktions legitimitet, kan en token returneras till handlaren istället för kortnumret, tillsammans med auktoriseringskoden för transaktionen. Token lagras i det mottagande systemet medan den faktiska kortinnehavarens data mappas till token i ett säkert tokeniseringssystem. Lagring av tokens och betalkortsdata måste följa gällande PCI-standarder, inklusive användning av stark kryptografi .
Standarder (ANSI, PCI Council, Visa och EMV)
Tokenisering finns för närvarande i standarddefinitionen i ANSI X9 som X9.119 Part 2 . X9 är ansvarig för branschstandarderna för finansiell kryptografi och dataskydd, inklusive hantering av betalkorts PIN-koder, kredit- och betalkortskryptering och relaterade teknologier och processer. PCI Council har också uttalat stöd för tokenisering för att minska risken vid dataintrång, i kombination med andra teknologier som Point-to-Point Encryption (P2PE) och bedömningar av överensstämmelse med PCI DSS-riktlinjer. Visa Inc. släppte Visa Tokenization Best Practices för användning av tokenisering i applikationer och tjänster för hantering av kredit- och betalkort. I mars 2014 EMVCo LLC sin första specifikation för betalningstokenisering för EMV . PCI DSS är den mest använda standarden för Tokenization-system som används av betalbranschens aktörer.
Riskreducering
Tokenisering kan göra det svårare för angripare att få tillgång till känslig data utanför tokeniseringssystemet eller tjänsten. Implementering av tokenisering kan förenkla kraven för PCI DSS , eftersom system som inte längre lagrar eller behandlar känslig data kan ha en minskning av tillämpliga kontroller som krävs av PCI DSS-riktlinjerna.
Som bästa säkerhetspraxis måste oberoende bedömning och validering av all teknik som används för dataskydd, inklusive tokenisering, finnas på plats för att fastställa säkerheten och styrkan hos metoden och implementeringen innan några påståenden om integritetsefterlevnad, regelefterlevnad och datasäkerhet kan bli gjord. Denna validering är särskilt viktig vid tokenisering, eftersom tokens delas externt i allmänt bruk och därmed exponeras i miljöer med hög risk och lågt förtroende. Omöjligheten att vända en token eller en uppsättning av tokens till en levande känslig data måste fastställas med branschgodkända mätningar och bevis av lämpliga experter oberoende av tjänsten eller lösningsleverantören.
Restriktioner för användning av token
Inte all organisationsdata kan tokeniseras och måste undersökas och filtreras.
När databaser används i stor skala expanderar de exponentiellt, vilket gör att sökprocessen tar längre tid, vilket begränsar systemets prestanda och ökar säkerhetskopieringsprocesserna. En databas som länkar känslig information till tokens kallas ett valv. Med tillägg av ny data ökar valvets underhållsarbete avsevärt.
För att säkerställa databaskonsistens måste tokendatabaser kontinuerligt synkroniseras.
Utöver det måste säkra kommunikationskanaler byggas mellan känslig data och valvet så att data inte äventyras på väg till eller från lagring.
Se även
externa länkar
- Cloud vs Payment - Cloud vs Payment - Introduktion till tokenisering via molnbetalningar.