Madrock

Jeg troede, vi var fjerne behovet for kontrol i den elektroniske tidsalder.

Tilsyneladende ikke, 'check' i denne sammenhæng på Engadget.

USAA's Depositum @ Mobile app lægger check indskud et krus skudt væk

Det er Great, jeg ønsker et af disse kort og en liste over Atma € ™ s.

http://www.sophos.com/blogs/gc/g/2009/03/18/details-diebold-atm-trojan-horse-case/

http://www.theregister.co.uk/2009/03/17/trojan_targets_diebold_atms/

Fra Security Now Podcast http://www.grc.com/sn/sn-200.htm

Hej,

For nylig har jeg en questing blev spurgt på en anden post i forbindelse med DUKPT. Da jeg har masser af materiale om emnet jeg troede, jeg ville oprette denne tråd. Link

Jeg vil vende tilbage på et tidspunkt og uddybe det, når jeg får tid.

Transaction Process fortælling:

Diagrammet beskriver en mobil terminal / ATM er beskrevet ved hjælp af en AS2805 ('2805 ') budskab type og 3DES DUKPT og dobbelt retning auth SSL fra terminalen til aquirer (transaktion switch).

En god forklaring på DUKPT kan også findes på Wikipedia .

Diagram over strømmen

DUKPT transaktion flow - terminal til bank

Baggrund noter:

• Den terminal eller ATM først krypterer brugeren har indtastet pin (kan være en enestående DUKPT nøgle eller statisk, afhængigt af design og banker involveret) forud for at integrere det i AS 2805 transaktion besked.
• Den besked er så krypteret igen ved brug af DUKPT nøgle, som er blevet etableret gennem de handlende logonprocessen i aquirer Host Security Module (HSM), dvs brugeren har indtastet PIN-koden er krypteret separat og indkapslet i DUKPT krypteret 2805 besked om at fremlægge fuld besked kryptering.
• I diagram en særskilt dobbelt autentifikation SSL session bruges også mellem terminal / ATM og aquirers infrastruktur. Dette giver en transaktion, herunder den pin til at krydse de ydre Wired / GPRS / LAN inden for 2 primære uafhængige lag af kryptering, med en 3 ^rd beskytte PIN-kode.
• Når transaktionen ind i aquirer miljøet beskeden indkapsling lag, som SSL er removed. Dette forlader DUKPTâ € ™ ed 2805 budskab, som også sammenfatter den separat krypteret PIN-kode.
• Dette krypteret besked ledes til aquirer skifte motoren igennem til aquirer's HSM for dekryptering af 2805 besked eksklusive brugeren har indtastet pin.
• Det er, når transaktionsbeslutning nødvendige oplysninger for aquirerâ € ™ s købmand indberetning (trunkeret kortnummer, transaktionsbeløbet, transaktion type osv.) og bedrageri forvaltning data er indsamlet.
• Den aquirer skifte derefter passerer krypteret PIN-kode til aquirer HSM anmoder om, at PIN blive afkodet ved hjælp af aquirer's PIN kryptering og oversat til det næste banker (Bank 1) Â PIN Encryption Key (Pin oversættelse kun sker inden for aquirer HSM) Dette er så sendt tilbage til aquirer Switch motoren som den bank 1 krypterede PIN-kode.
• Den aquirer skifte motoren derefter sende den afkodede 2805 besked med det nyligt krypterede PIN tilbage til aquirer HSM, som skal krypteres med Banken 1 MAC nøgle.
• Den resulterende Bank 1 nøgle krypteret besked er derefter sendt til bank 1 til forarbejdning og / eller passere til kortudstederen (ved hjælp af en lignende proces som beskrevet ovenfor).
• Når resultatet er modtaget fra den udstedende bank er krypteret med Bank 1 MAC-nøgle (pin vil ikke være til stede i resultatet besked).
• Dette er så dekrypteret af aquirer HSM, transaktionen skæbne resultat gemt i aquirer købmand rapporteringssystem, og transaktionen skæbne re-krypteret med den oprindelige aquirer DUKPT nøgle (burde være anderledes pr terminal / købmand instans), og resultatet sendes tilbage til terminal gennem den oprindelige etableret SSL krypteret terminal forbindelse.

Den aquirer kan opsige den SSL-forbindelse på en hardwareenhed, f.eks en CISCO Content Service Switch (CSS), eller tilsvarende i stedet for design, der er beskrevet i diagrammet som ender på en SSL-session server / gateway (herunder eventuelt en Certificate Authority) eller om aquirer transaktionen switch.

Når PIN-kode blokke bliver modtaget af aquirer datacentrets PIN kryptering er oversat fra terminalen nøglen til den lokale Master Key (LMK) af Host Security Modules (HSM).

Når beskeden er sendt på upstream-bank-udfletning link til udstederen eller gateway, den aquirer HSM oversætter krypterede PIN blok fra LMK til Zone hovednøgle (ZMK) i aquirer udveksling link. PIN-blokken er altid krypteret vha. DEA3 (3DES) når uden for Terminal eller ATM.

HSM-8000-User Guide V2.2

EFT udstyr og systemer varierer afhængigt af hardware leverandør, land og bank / betaling nyhedslæser.
Herunder er en liste over ting, du kan lide at overveje. Denne liste er slukket toppen af mit hoved, så det er nok ikke komplet.

Ser man på de produkter og relationer os normalt en god start.

Ting at overveje:

• Card skimming metoder
• Nogle EFT POS udstyr begrænse tilslutningen af en hulske
• Revision niveauer af associerede bedrageri
• Revision udstyr og EFT metoder
• Review terminal identifikation (købmand og kunde)
• Manuel behandling. (Interne og eksterne)
• eCommerce produkter
• PC-baseret software
• Dedikeret server-tjenester (Nobil, etc.)
• Web baseret motor (Custom genstande, Web pop-ups, osv.)
• Tilladelse / identifikation metoder (Merchant og kunde)
• TCPIP sessionskapring / session spoofing
• Direkte Debit samt Credit Cards.
• Swift (metoder og kontrol)
• Telegrafisk overførsel (metoder og kontrol)
• Betaling nyhedslæser relationer (f.eks Betaling Tech, manuel behandling, check scanning, osv.)
• Internetbanker faciliteter (angreb / penetration, et certifikat, registrering / forvaltning, ISP SLA's, osv.)
• Gennemførelse af Smart Card og / eller alternative kunde anerkendelse enheder.
• Outsourcing og tilknyttede risici / service level agreements
• Betaling forarbejdning
• Betaling clearance
• Betaling skifte
• Rapportering (adskillelse af handelsskibe / kunder / nyhedslæsere / partnere / lokal / international)
• Opsporing af svig og rapportering
• 3. parts erhverve risici
• Single købmand ID mange virksomheder
• Tillader penge, der skal hvidvaskes, hvis betalingen aggregator ikke egnede kontrol af handelsskibe.
• Kryptering, der anvendes
• Internet / betroede partner / inter-bank / extranet
• Private og / eller offentlige certifikater
• Single bruger certifikater
• Client side certifikater
• Remittance rådgivning processer og kontroller.
• EFT disaster recovery og manuel falde tilbage procedurer (tilhørende sikkerhed og forsoning risici)
• Trusted partner relationer, SLA's, passiver og risici.
• EFT regulering / lovkrav (inter-bank og staten)
• Refusion behandling / godkendelse. (Politikker, procedurer, kontrol, etc.)
• CVV, CVV-2 / CVC-2 behandling og forvaltning. (Http://www.atlanticpayment.com/CVV.htm)
• Opsporing af svig mekanisme (neurale netværk, inter-bank / afdeling kunde kontrol osv.)
• Understøttet kortsystemer (AMEX / Visa / Mastercard / Discover / etc)
• Revision EFT gulv grænser (corporate og SMV købmænd)
• Revision evnen til at tilbageholde købmand løsning indtil forekomsten af svig er blevet fastlagt.
• Revision kundeidentifikation detaljer. Såsom (Dette varierer rundt om i verden afhængig af lokale regler / love om privatlivets fred)
• Review real-time og batched forarbejdningsmetoder og kontrol (sekvensnumre, adgang til rå data, osv.)
• Revision behandling med og uden udløbsdato. (Undtagelse kontrol og politikker)
• Review undtagelse / svig rapporter.
• Revision betaling opbevare og videresende politikker og procedurer.
• Review Præ-Auth og supplering kontrol.
• Token aktiebaseret vederlæggelse (eCash, etc)
• Merchant forsoning, rapportering metoder og kontrol (papir, internet, e-mail, PDF, Fax, osv.) og tilknyttede sikkerhedstjenester.
• Realtidsbruttosystemer politikker, procedurer og kontroller. (IT og beløb)
• Kortudstedende politikker og procedurer. (Kunde-id kontrol osv.)
• Banker infrastruktur (indtrængen ind-/udgangsdøre) kontrol og sikkerhed. (Web, partner, betaling switches, outsourcet infrastruktur, overvågning / rapportering.)
• Brug af Internet teknologi til interbank-overførsler og fjerntliggende udstyr.
• Fysisk sikkerhed og kontrol af udstyr, ATM, s, linje encryptors osv.

Jeg blev spurgt for nogen tid siden, hvad slags ting kan overvejes, når man ser på Internet Banking.

Nedenfor er en liste over ting, som kunne overvejes. Det var bare en hjerne dump og som sådan kan ikke være komplet.

Må ikke undervurdere værdien af standard for din infrastruktur, website konfiguration, Â database motorer / arkitektur, iscenesættelse miljø og udvikling / QA miljøer.

Nogle tanker:

• Mange gør ikke låse regnskabet efter X mislykkedes logins, er det normalt sker for god kundeservice, men overlader det system sårbart.

- Og alle de andre ting der forventes for en ekstern login-session (forceret password ændringer, aldring, osv.))
- Værktøjer som Brutus kan bruge til at brute force hack bekræftet sessioner.

• Mange tillade session sekvensnumre skal øges, så en godkendt bruger for at se anden kunde session.

- Der kan være server side, klientsiden cookie baseret, etc.
- Få nogen til at kontrollere udviklingen metoder og koden bliver brugt.
- Database query strings kan placeres i test indtastningsfelter, så bordet lossepladser, til browser.
- Check alt serveret sider sikkert og indeholder brugergodkendelse flag.

• Kundedata kan ikke holdes adskilt, dette skal kontrolleres.
• Kundedata bør ikke opholde sig på Web Server.

• Authentication databaser / system data bør ikke opholde sig på den webserver.
• Databaserne skal opholde sig på en privat / semi-privat netværk.

- En anderledes segment til de vigtigste banksystemet.

• Webserver bør dobbelt homed eller tilsvarende (nogle VLAN teknikker er gode)

- Separate private og offentlige netværkskort, overvågning / backup / administration
- Infrastruktur set-up til udtrykkeligt benægte indgående / udgående porte, private IP & overvågning flygter fra netværket.

• Under alle data adskillelse punkter sikre, at reglerne er på plads, som værdsætter trafik selvom det punkt.

• Alle kundedata hvor det er muligt må stamme fra en sikker back-end database.

- Det kan være en mellemstation miljø. dvs de vigtigste banksystemet.
- Denne regel giver mulighed for transaktioner vises i realtid til kunden.
- Mange transaktioner kan batched i virkeligheden. (Intern eller ekstern i forhold til bank)

• Sikre passende regler er blevet sat op på firewalls.

- Der bør være indgående og udgående regler om firewalls og filtrering routere.

• Lad ikke nogen infrastruktur på frontend for at tillade eksterne administrative forbindelser. (Telnet, etc.)

- Brug den serielle konsol port til at forbinde til en server eller back-end terminal server.

• Se efter adskillelse / iscenesættelse af online-kunde indhold fra vigtigste banksystemer

• Sørg for, at en separat udvikling / QA / produktionsmiljø, og hertil egnede processer er på plads.

• Tjenester, der ikke bruges af systemet er aktive

- Disse skal deaktiveres.

• Port scanning af understøttende infrastruktur (router / switches) og server (s).

- Undersøge årsagerne til alle åbne porte.

• Brug ikke den vigtigste gateway for betroede partner adgang (clearing / RAS / etc.)
• Gøre alt, hvad standard IIS kontrol og NT kontrol (Sample scripts, forandringsledelse, patching metoder, osv.)
• Sikre denial of service forholdsregel er taget højde for alle infrastruktur og server udstyr.
• Check tilstrækkeligheden af den optrapning, der anvendes.

- Kig efter real-time overvågning og alarmering.
- Kig efter ansvar matrix.
- Se efter ejerskab af spørgsmål.

• Overvej upstream (e) luftfartsselskab sårbarhed (denial of service, IP spoofing, DNS hacking, etc)
• Overvej social engineering af kunde, administrative, partner accounts / systemer / infrastruktur.

- Helpdesk procedurer og politikker og / eller alternative teknologier (Caller ID, Gateway IP, etc.).

• Brug dynamiske passwords hvor det er muligt (SecureID, TACACS osv.).
• Brug krypteret tunnel hvor der er behov (IPSec, Firewall 1 osv.)
• Overvej at kigge på andre kunder authentication metoder til at forbedre de eksisterende metoder.

- Digital cert, IP-adresse låst til regnskab mv
- Overvej brug af CVV eller CVN for bank udstedte kort.

• Overvej hvordan passwords er fordelt / ændres for kunderne.

- Almindelig tekst e-mail, telefon osv.
- Kan passwords ændres online?

• Er yderligere godkendelse anvendes mellem dele af tjenester, når bekræftet?
• Overvej, hvad kunden har adgang til en gang bekræftet.

- Se på SWIFT, RTGS, inter-bank overførsler, adgang til kredit kort, etc.
- Hvis en hacker har får i, hvad kan de gøre?

• Brug teknikker til at sikre sider, kundeoplysninger ikke caches på ISP eller klient system.

- Disse er flag, der kan indstilles i siderne.
- Normalt SSL er cachet, men nogle proxy leverandører har spillet med teknikker til at gøre det.
- Caching af SSL sider på klienten system kan tændes på nogle browsere.
- Kan banker anvender en Java (eller lignende) applet for alle kundernes interaktion, der begrænser alle caching spørgsmål.

• Sikre papirbaserede og on-line ansvar klausuler er til rådighed, tage fat på alle berørte områder.
• Sikre inden kunden sign-up proces bank ansvar er reduceret.

- Jeg har set udsagn som "bruge dette system på egen risiko, ansvar for ethvert ansvar eller krav vil IKKE ... ..."
- Ikke meget kundefokuseret, men det er, hvad deres juridiske afdeling anbefales.

Alle ovenstående kan påvirke sikkerheden og / eller drift af en on-line banking system.

Andre ting at overveje:

• Eksterne udvikling og support af ansøgningen.
• Ejerskab og forvaltning af hardware / applikationer
• Publishing point for nyt indhold (intern / privat / betroede netværk eller internettet)
• Topologi front end. dvs Security Architecture dokument skal være på plads og forvaltes ordentligt.
• Er begrænset AP test, når der foretages ændringer for miljøet? dvs. integreret AP i Change Management processen.
• Database adgang. Er det buffered eller er det live til kernen banksystemer.
• Hvilke faciliteter er til rådighed? Direkte debitering + Kreditkort + SWIFT + ... .... Overvej forskellige scenarier for dine angreb, afhængigt af funktionen.
• Hvilke andre tjenester er delt i netafsnit, at Internet Banking service kører. Kan dette bruges til at kompromittere Internet Banking site. f.eks. forskellige støtteordninger / business / udviklingsorganisationer med forskellige sikkerhedsstrategier / profiler.
• Overvej alle eksterne støttetjenester inden du AP. Kig på interne / eksterne DNS forgiftning muligheder, mail relay, osv. Hvad IPS 'bruger de har ISP nogen mulighed for at få adgang til systemer eller støtte tjenester, der kan påvirke Internet Banking.
• Afhængig af størrelsen af banken, mange organisation ikke bruge den samme støtte grupper for infrastruktur og anvendelse. Som et resultat eksterne forbindelser til infrastrukturen kan leveres til en ekstern støtte organisation til at administrere infrastrukturen.
• Kig på forretnings-og brugergodkendelse metoder og ruter (klientsiden certs, sikker ID, SMART-kort, etc). Overvej to-faktor autentificering og moderne brugeridentifikation metoder. f.eks. hvad er din livret ud over normal brugernavne og passwords. Må systemadministration ansatte benytter dynamisk adgangskoder (SecureID, osv.)?
• Se, om Internet Banking ansøgning sender e-mail til brugerne, som kan indeholde interessante oplysninger.
• Bedre adgang til ansøgningen kan generelt opnås efter adgang til systemet. dvs få en legitim konto på systemet. Jeg har konstateret, at nogle prøve / administration skærme har været begrænset til godkendte brugere alene.
• Overvej social engineering Hjælp desk at have en konto password reset.

Når det overvejes Mobile Banking sikkerhed og den dermed forbundne risiko, en vurdering tilgang afhænger i høj grad på den løsning, der skaber eller leveres.
Generelt tilgang er baseret på lag standarder til støtte og de omkringliggende teknologier og teknikker, der anvendes.

Her er nogle ting at overveje.

Sårbarhedsvurderinger generelt fokuserer på to vigtigste ting.

1 / Følsomhed af data
Hvad bliver sendt. f.eks. Pin, kreditkortnumre, konto, hjemme adresse, bankkontonummer, etc.
Data kan ikke være følsom over for banken, men kan betragtes som kunden som følsomme.
etc ... ... ....

2 / Mulighed for at få adgang til data.
Hvad medium bliver brugt?
Er det nemt at hacke?
Hvad kryptering bliver brugt?
Er alle datastier sikker (kunde-og back end)?
Er der en 3. part involveret i koblingen af transaktionerne?
etc ... ... ...

Ting at overveje:

• Pin nulstiller sendt via SMS til kunden, bør ikke anvendes som den eneste metode til at få adgang regnskaber. En yderligere kundespecifikke (eventuelt statisk) pass ord / sætning bør anvendes som supplement til en dynamisk genereret PIN-kode. SMS kan indsnuses (afhængigt mode og placering).
• Hvis WAP anvendes, er alle apparater, som kan kryptering? Hvis enhederne ikke er i stand til kryptering, vi nægte adgang til disse enheder? Hvis klientsiden JAVA eller intelligent enhed (vinder CE, osv.), sikre, at dette ikke kan kompromitteres af en Trojan's og andre centrale logning teknikker.
• Har organisationen betragtes klientsiden certifikater til at kontrollere enheden før transaktionerne er accepteret? Overvej flere enheds-og bruger identifikationsmetoder (meget løsning afhængig).
• De fleste mobile POS terminaler kryptere kundens trådte Pin nummer, men ikke kryptere alt inden transaktionen. Hvis transmission medium er bortkommet, bør vi overveje, om kryptering kan krakket, og hvis ikke krypterede data er følsom. Overveje yderligere data kryptering indkapsling dvs. anvendelse af alle besked kryptering (SSL, IPSec) eller bruge en terminal, der bruger Afledte Unikke Key Per Transaction (DUKPT).
• Mange banking er blevet påvirket af typiske hacks, såsom sessionskapring, SQL injektion, ikke tilfældige sessionsnøgler (klient side og server side), etc ... Disse typiske hacks bør overvejes i din Secure SDLC og QA Processer, når du er klar over teknologi, der anvendes og / eller anvendes.
• PBX systemer og kabler distribution rammer kan have enheder tilsluttet til at indsamle transaktioner. Trådløse enheder er nu forbundet til disse systemer. Angriberen sidder i deres bil på parkeringspladsen udenfor. Dette sker ofte i super markeder.
• Trådløs transaktion gateways, hvis ikke krypteret er let indsamles af alle inden for trådløs rækkevidde. 802,11 og andre trådløse / infrarød medier bliver brugt (vurdere, hvilken teknologi og medium er anvendt).
• Har organisationen betragtes dynamiske nøgler til mobile brugere? Der er nogle meget lave omkostninger SecureID type løsninger til rådighed i dag, men kunderne nødt til at have disse enheder på dem, når de ønsker at gøre en transaktion.

Nedenfor er en artikel jeg fandt for nylig. Denne ene af de mest omfattende beskrivelser af PIN Verifikation Værdi (PVV) hacking.

Jeg troede, jeg ville kopiere det her for min lokale reference.

Som har fremsat bemærkninger om grammatik anvendt i den oprindelige tekst, har jeg rettet nogle af de åbenlyse fejl og samtidig opretholde rammerne af det oprindelige materiale.

http://69.46.26.132/ ~ biggold1/fastget2you/tutorial.php

--- Original tekst ----

Forord
Har du nogensinde spekulerer på, hvad der ville ske, hvis du mister dit kredit-eller betalingskort, og nogen finder den. Ville denne person være i stand til at hæve kontanter fra en pengeautomat gætte, en eller anden måde, din PIN-kode? Desuden, hvis du var der finder en eller andens kort ville du så prøve at gætte PIN og tage chancen for at få nogle nemme penge? Selvfølgelig svaret på begge spørgsmål bør være "nej". Dette arbejde beskæftiger sig ikke med det andet spørgsmål, det er et spørgsmål om personlig etik. Hermed forsøger jeg at besvare det første spørgsmål.

Alle oplysninger, der anvendes til dette arbejde er offentlig og frit kan findes i Internet. Resten er et spørgsmål om matematik og programmering, så vi kan lære noget og have det sjovt. Jeg afslører ingen hemmeligheder. Herudover sigtes mod (og endelig konklusion) i dette arbejde er at vise, at PIN algoritmer stadig er stærk nok til at give tilstrækkelig sikkerhed. Vi ved alle, teknologi er ikke det svage punkt.

Dette arbejde analyser et af de mest almindelige PIN algoritmer, VISA PVV, som anvendes af mange ATM-kort (kredit-og betalingskort) og forsøger at finde ud af, hvordan resistente er at PIN gætte angreb. Ved "gætte" Jeg mener ikke at vælge en tilfældig PIN-kode og prøve det i en ATM. Det er velkendt, at vi generelt får tre på hinanden følgende forsøg for at indtaste den rigtige PIN-kode, hvis vi ikke ATM holder kortet. Som VISA PIN er fire-cifret lang tid det er nemt at udlede, at chancen for en tilfældig PIN gætte er 3/10000 = 0,0003, synes det lave nok til at være sikker, det betyder, at du skal miste dit kort mere end tre tusinde gange (eller tabe mere end tre tusinde kort på samme tid:), indtil der er en rimelig chance for at tabe penge.

Hvad jeg egentlig mente med "at gætte" var at bryde PIN-algoritmen, så givet nogen kort, du straks kan kende de associerede PIN-kode. Derfor dette dokument undersøgelser denne mulighed, analysere algoritmen og foreslår en metode til angreb. Endelig giver vi et redskab, der gennemfører angreb og præsentere resultater om den anslåede chance for at bryde systemet. Bemærk, at så længe andre banker sikkerhedsrelaterede algoritmer (andre PIN formater såsom IBM PIN-kode eller kort validering signaturer som CVV eller CVC) ligner VISA PIN-kode, samme analyse kan gøres fremstilling næsten de samme resultater og konklusioner.

VISA PVV algoritme

En af de mest almindelige PIN algoritmer er VISA PIN Kontrol Værdi (PVV). Kunden har fået en PIN-kode og en magnetstribe-kort. Kodet i det magnetiske stribe er en fire-cifret nummer, kaldet PVV. Dette nummer er en kryptografisk signatur af PIN og andre data til kortet. Når en bruger indtaster sin PIN ATM læser magnetstribe, krypterer og sender alle disse oplysninger til en central computer. Der en retssag PVV beregnes ved hjælp af kunden ind PIN og kort information med en kryptografisk algoritme. Forsøget PVV sammenlignes med PVV lagret på kortet, hvis de svarer til den centrale computer tilbage til ATM tilladelse til transaktionen. Se mere detaljeret.

Beskrivelsen af PVV algoritme kan findes i to dokumenter med tilknytning i den foregående side. Sammenfattende består i krypteringen af en 8 byte (64 bit) streng af data, kaldet Transformeret Sikkerhed Parameter (TSP), med DES algoritme (DEA) i elektronisk kodebog mode (ECB) med en hemmelig 64 bit nøgle. PVV stammer fra produktionen af krypteringen, hvilket er en 8 byte streng. De fire cifre i PVV (fra venstre mod højre) svarer til de fire første decimaler (fra venstre mod højre) af produktionen fra DES, når de betragtes som en 16 hexadecimale tegn (16 x 4 bit = 64 bit) streng. Hvis der ikke er fire cifre cifre blandt de 16 hexadecimale tegn derefter PVV er afsluttet tages (fra venstre mod højre) ikke decimal tegn og decimalizing dem ved hjælp af omstillingen A-> 0, B-> 1, C-> 2, D -> 3, E-> 4, F-> 5. Her er et eksempel:

Output fra DES: 0FAB9CDEFFE7DCBA

PVV: 0975

Strategien med at undgå decimaltal ved at springe karakterer indtil fire Decimaler findes (som tilfældigvis er næsten alle de gange vi vil se nedenfor) er meget smart, fordi man derved undgår en vigtig skævhed i fordelingen af cifre, der har vist sig at være fatal for andre systemer, selv om indvirkningen på dette system vil være meget lavere. Se også en beslægtet problem ikke finder anvendelse på VISA PVV.

Det TSP, ses som en 16 hexadecimale tegn (64 bit) streng, som dannes (fra venstre mod højre) med de 11 yderste højre cifre i PAN (kortnummer), bortset fra det sidste ciffer (check ciffer), et tal fra 1 til 6 der vælger den hemmelige krypteringsnøgle, og endelig de fire cifre i PIN-koden. Her er et eksempel:

PAN: 1234 5678 9012 3445
Key vælgeren: 1
PIN-kode: 2468

TSP: 5678901234412468

Naturligvis problem at bryde VISA PIN består i at finde den hemmelige krypteringsnøgle for DES. Metoden herfor er at lave en brute force søgning af de centrale rum. Bemærk at dette ikke er den eneste metode, kan man forsøge at finde en svaghed i DEA, mange har forsøgt, men denne gamle standard stadig er i udbredt anvendelse (nu erstattet af AES og RSA, selv om). Det viser det er robust nok til, at brute force er den eneste levedygtige metode (der er nogle bedre angreb, men ikke praktisk i vores tilfælde, for et resumé se LASEC memo og for de beskidte detaljer se Biham & Shamir 1990, Biham & Shamir 1991, Matsui 1993, Biham & Biryukov 1994 og Heys 2001).

De vigtigste vælgeren cifret var meget sandsynligt tale om at dække muligheden for et centralt kompromis. I så fald er de bare nødt til at udstede nye kort med en anden nøgle selector. Ældre kort kan erstattes med nye eller blot ATM kan gennemsigtig skrive en ny PVV (svarende til den nye nøgle og holde samme PIN) næste gang kunden bruger hans / hendes kort. For ryste af sikkerheden for alle brugere bør anmodes om at ændre deres PIN-koder, men det ville være pinligt for banken at forklare grunden, så meget sandsynligt, at de ikke ville gøre sådan anmodning.

Forberedelse af angreb

En brute force angreb består i at kryptere en TSP med kendte PVV med alle mulige kryptering nøgler og sammenligne hver fremstillet PVV med den kendte PVV. Når der findes et match, vi har en kandidat nøgle. Men hvor mange nøgler vi nødt til at prøve? Som vi sagde ovenfor nøglen er 64 bit lang, ville dette betyde, at vi er nødt til at forsøge 2 ^ 64 nøgler. Men det er ikke sandt. Faktisk kun 56 bits er effektive i DES-nøgler, fordi en smule (det mindst vigtige) ud af hver oktet var historisk reserveret som en checksum for de andre, i praksis de 8 bit (en for hver af de 8 octets) ignoreres.

Derfor DES nøglen plads består af 2 ^ 56 nøgler. Hvis vi forsøger alle disse nøgler vil vi finde én og kun én kamp, hvilket svarer til banken hemmelige nøgle? Bestemt ikke. Vi vil få mange matchende nøgler. Dette skyldes, at PVV er kun en lille del (fjerdedel) af DES output. Desuden PVV er degenererede, fordi nogle af cifrene (dem mellem 0 og 5 efter den sidste, set fra venstre mod højre, tal mellem 6 og 9) kan komme fra en decimal tal eller fra en decimalized hexadecimal ciffer i DES output. Således er mange nøgler vil producere en DES output, der giver de samme matchende PVV.

Så hvad kan vi gøre for at finde den rigtige nøgle blandt de andre falsk positive nøgler? Blot vi er nødt til at kryptere en anden anderledes TSP, også med kendte PVV, men kun bruger den kandidat nøgler, der gav en positiv tilpasning til den første TSP-PVV par. Der er dog ingen garanti, vil vi ikke få igen mange falske positiver sammen med den sande nøgle. Hvis det er tilfældet, vil vi være nødt tredjedel TSP-PVV par, skal du gentage processen og så videre.

Før vi starter vores angreb har vi at vide, hvor mange TSP-PVV par vi får brug for. For at vi skal beregne sandsynligheden for en tilfældig DES output til at give et matchende PVV netop ved en tilfældighed. Der er flere måder at beregne dette antal, og her vil jeg bruge en simpel metode er let at forstå, men som kræver en vis baggrund i matematik af sandsynlighed.

En sandsynlighed kan altid ses som forholdet mellem favorable tilfælde af eventuelle sager. I vores problem at antallet af mulige tilfælde er givet ved permutation af 16 elementer (0 til F hexadecimale cifre) i en gruppe på 16 af dem (de 16 hexadecimale cifre i DES output). Dette er givet ved 16 ^ 16 ~ 1,8 * 10 ^ 19, som naturligvis er sammenfaldende med 2 ^ 64 (forskelligt antal 64 bit). Dette sæt af numre kan opdeles i fem kategorier:

Personer med mindst fire decimaler (0 til 9) blandt de 16 hexadecimale cifre (0 til F) af DES output.

Personer med præcis kun tre decimaler.

Personer med præcis kun to decimaler.

Personer med præcis én decimal ciffer.

Dem uden Decimaler (alle mellem A og F).

Lad os beregne, hvor mange numre falder i hver kategori. Hvis vi mærker de 16 hexadecimale cifre i DES output som X1 til X16 så kan vi mærke de første fire cifre cifre i et givet antal den første kategori som Xi, XJ, XK og XL. Antallet af forskellige kombinationer med denne profil er givet ved produktet 6 i-1 * 10 * 6j-i-1 * 10 * 6k-j-1 * 10 * 6 lk-1 * 10 * 1616-l, hvis 6 " s kommer fra antallet af muligheder for en A til F ciffer, de 10 er kommet fra mulighederne for en 0 til 9 cifre, og de 16 kommer fra mulighederne for en 0 til F ciffer. Nu det samlede antal i den første kategori er simpelthen givet ved sammenlægning af dette produkt over i, j, k, l 1 til 16, men med i <j <k <l. Hvis du har nogle matematik arbejde, du vil se denne lig med produktet af 104 / 6 med sammenlægning over i 4 til 16 i (i-1) * (i-2) * (i-3) * 6i-4 * 16 16-i ~ 1,8 * 1019.

Analogt antallet af sager i den anden kategori er givet ved summation over i, j, k 1 til 16 med i <j <k af produktet 6i-1 * 10 * 6j-i-1 * 10 * 6k-j -1 * 10 * 616-k, hvor du kan finde ud af det at være 16! / (3! * (16-13)!) * 103 * 6 13 = 16 * 15 * 14 / (3 * 2) * 103 * 613 = 56 * 104 * 613 ~ 7,3 * 1015. Tilsvarende for den tredje kategori har vi summation over i, j 1 til 16 med i <j af 6 i-1 * 10 * 6j-i-1 * 10 * 616-j hvilket svarer til 16! / (2! * (16-14)!) * 102 * 614 = 2 * 103 * 615 ~ 9,4 * 1014. Igen, for den fjerde kategori har vi summation over i fra 1 til 16 i 6i-1 * 10 * 616-i = 160 * 615 ~ 7,5 * 1013. Og endelig mængden af sager i den femte kategori er givet ved permutation af seks elementer (A til F cifre) i en gruppe på 16, det vil sige 616 ~ 2,8 * 1012.

Jeg håber du har fulgt de beregninger, op til dette punkt, er den svære del færdig. Nu som bevis for, at alt er til højre kan du summen af antallet af tilfælde i de 5 kategorier og se det svarer til det samlede antal mulige sager vi beregnet før. Gør operationer med brug af 64 bit tal eller afrunding (for flåd) eller overflow (for heltal) fejl ikke vil lade dig få præcise resultat.

Indtil nu har vi beregnet antallet af mulige tilfælde i hver af de fem kategorier, men vi er interesseret i at få antallet af gunstige tilfælde i stedet. It is very easy to derive the latter from the former as this is just fixing the combination of the four decimal digits (or the required hexadecimal digits if there are no four decimal digits) of the PVV instead of letting them free. In practice this means turning the 10′s in the formula above into 1′s and the required amount of 6′s into 1′s if there are no four decimal digits. That is, we have to divide the first result by 104, the second one by 103 * 6, the third one by 102 * 62 , the fourth one by 10 * 63 and the fifth one by 64 . Then the number of favorable cases in the five categories are approximately 1.8 * 1015, 1.2 * 1012, 2.6 * 1011 , 3.5 * 1010, 2.2 * 109 respectively.

Now we are able to obtain what is the probability for a DES output to match a PVV by chance. We just have to add the five numbers of favorable cases and divide it by the total number of possible cases. Doing this we obtain that the probability is very approximately 0.0001 or one out of ten thousand. Is it strange this well rounded result? Not at all, just have a look at the numbers we calculated above. The first category dominates by several orders of magnitude the number of favorable and possible cases. This is rather intuitive as it seems clear that it is very unlikely not having four decimal digits (10 chances out of 16 per digit) among 16 hexadecimal digits. We saw previously that the relationship between the number of possible and favorable cases in the first category was a division by 10^4, that's where our result p = 0.0001 comes from.

Our aim for all these calculations was to find out how many TSP-PVV pairs we need to carry a successful brute force attack. Now we are able to calculate the expected number of false positives in a first search: it will be the number of trials times the probability for a single random false positive, ie t * p where t = 2^56, the size of the key space. This amounts to approximately 7.2 * 10^12, a rather big number. The expected number of false positives in the second search (restricted to the positive keys found in the first search) will be (t * p) * p, for a third search will be ((t * p) * p) * p and so on. Thus for n searches the expected number of false positives will be t * p^n.

We can obtain the number of searches required to expect just one false positive by expressing the equation t * p^n = 1 and solving for n. So n equals to the logarithm in base p of 1/t, which by properties of logarithms it yields n = log(1/t)/log(p) ~ 4.2. Since we cannot do a fractional search it is convenient to round up this number. Therefore what is the expected number of false positives if we perform five searches? It is t * p^5 ~ 0.0007 or approximately 1 out of 1400. Thus using five TSP-PVV pairs is safe to obtain the true secret key with no false positives.

The attack

Once we know we need five TSP-PVV pairs, how do we get them? Of course we need at least one card with known PIN, and due to the nature of the PVV algorithm, that's the only thing we need. With other PIN systems, such as IBM, we would need five cards, however this is not necessary with VISA PVV algorithm. We just have to read the magnetic stripe and then change the PIN four times but reading the card after each change.

It is necessary to read the magnetic stripe of the card to get the PVV and the encrypting key selector. You can buy a commercial magnetic stripe reader or make one yourself following the instructions you can find in the previous page and links therein. Once you have a reader see this description of standard magnetic tracks to find out how to get the PVV from the data read. In that document the PVV field in tracks 1 and 2 is said to be five character long, but actually the true PVV consists of the last four digits. The first of the five digits is the key selector. I have only seen cards with a value of 1 in this digit, which is consistent with the standard and with the secret key never being compromised (and therefore they did not need to move to another key changing the selector).

I did a simple C program, getpvvkey.c, to perform the attack. It consists of a loop to try all possible keys to encrypt the first TSP, if the derived PVV matches the true PVV a new TSP is tried, and so on until there is a mismatch, in which case the key is discarded and a new one is tried, or the five derived PVVs match the corresponding true PVVs, in which case we can assume we got the bank secret key, however the loop goes on until it exhausts the key space. This is done to assure we find the true key because there is a chance (although very low) the first key found is a false positive.

It is expected the program would take a very long time to finish and to minimize the risks of a power cut, computer hang out, etc. it does checkpoints into the file getpvvkey.dat from time to time (the exact time depends on the speed of the computer, it's around one hour for the fastest computers now in use). For the same reason if a positive key is found it is written on the file getpvvkey.key. The program only displays one message at the beginning, the starting position taken from the checkpoint file if any, after that nothing more is displayed.

The DES algorithm is a key point in the program, it is therefore very important to optimize its speed. I tested several implementations: libdes, SSLeay, openssl, cryptlib, nss, libgcrypt, catacomb, libtomcrypt, cryptopp, ufc-crypt. The DES functions of the first four are based on the same code by Eric Young and is the one which performed best (includes optimized C and x86 assembler code). Thus I chose libdes which was the original implementation and condensed all relevant code in the files encrypt.c (C version) and x86encrypt.s (x86 assembler version). The code is slightly modified to achieve some enhancements in a brute force attack: the initial permutation is a fixed common steep in each TSP encryption and therefore can be made just one time at the beginning. Another improvement is that I wrote a completely new setkey function (I called it nextkey) which is optimum for a brute force loop.

To get the program working you just have to type in the corresponding place five TSPs and their PVVs and then compile it. I have tested it only in UNIX platforms, using the makefile Makegetpvvkey to compile (use the command “make -f Makegetpvvkey”). It may compile on other systems but you may need to fix some things. Be sure that the definition of the type long64 corresponds to a 64 bit integer. In principle there is no dependence on the endianness of the processor. I have successfully compiled and run it on Pentium-Linux, Alpha-Tru64, Mips-Irix and Sparc-Solaris. If you do not have and do not want to install Linux (you don't know what you are missing ;-) you still have the choice to run Linux on CD and use my program, see my page running Linux without installing it.

Once you have found the secret bank key if you want to find the PIN of an arbitrary card you just have to write a similar program (sorry I have not written it, I'm too lazy :) that would try all 10^4 PINs by generating the corresponding TSP, encrypting it with the (no longer) secret key, deriving the PVV and comparing it with the PVV in the magnetic stripe of the card. You will get one match for the true PIN. Only one match? Remember what we saw above, we have a chance of 0.0001 that a random encryption matches the PVV. We are trying 10000 PINs (and therefore TSPs) thus we expect 10000 * 0.0001 = 1 false positive on average.

This is a very interesting result, it means that, on average, each card has two valid PINs: the customer PIN and the expected false positive. I call it “false” but note that as long as it generates the true PVV it is a PIN as valid as the customer's one. Furthermore, there is no way to know which is which, even for the ATM; only customer knows. Even if the false positive were not valid as PIN, you still have three trials at the ATM anyway, enough on average. Therefore the probability we calculated at the beginning of this document about random guessing of the PIN has to be corrected. Actually it is twice that value, ie, it is 0.0006 or one out of more than 1600, still safely low.

Results

It is important to optimize the compilation of the program and to run it in the fastest possible processor due to the long expected run time. I found that the compiler optimization flag -O gets the better performance, thought some improvement is achieved adding the -fomit-frame-pointer flag on Pentium-Linux, the -spike flag on Alpha-Tru64, the -IPA flag on Mips-Irix and the -fast flag on Sparc-Solaris. Special flags (-DDES_PTR -DDES_RISC1 -DDES_RISC2 -DDES_UNROLL -DASM) for the DES code have generally benefits as well. All these flags have already been tested and I chose the best combination for each processor (see makefile) but you can try to fine tune other flags.

According to my tests the best performance is achieved with the AMD Athlon 1600 MHz processor, exceeding 3.4 million keys per second. Interestingly it gets better results than Intel Pentium IV 1800 MHz and 2000 MHz (see figures below, click on them to enlarge). I believe this is due to some I/O saturation, surely cache or memory access, that the AMD processor (which has half the cache of the Pentium) or the motherboard in which it is running, manages to avoid. In the first figure below you can see that the DES breaking speed of all processors has more or less a linear relationship with the processor speed, except for the two Intel Pentium I mentioned before. This is logical, it means that for a double processor speed you'll get double breaking speed, but watch out for saturation effects, in this case it is better the AMD Athlon 1600 MHz, which will be even cheaper than the Intel Pentium 1800 MHz or 2000 MHz.

In the second figure we can see in more detail what we would call intrinsic DES break power of the processor. I get this value simply dividing the break speed by the processor speed, that is, we get the number of DES keys tried per second and per MHz. This is a measure of the performance of the processor type independently of its speed. The results show that the best processor for this task is the AMD Athlon, then comes the Alpha and very close after it is the Intel Pentium (except for the higher speed ones which perform very poor due to the saturation effect). Next is the Mips processor and in the last place is the Sparc. Some Alpha and Mips processors are located at bottom of scale because they are early releases not including enhancements of late versions. Note that I included the performance of x86 processors for C and assembler code as there is a big difference. It seems that gcc is not a good generator of optimized machine code, but of course we don't know whether a manual optimization of assembler code for the other processors (Alpha, Mips, Sparc) would boost their results compared to the native C compilers (I did not use gcc for these other platforms) as it happens with the x86 processor.

Update

Here is an article where these techniques may have been used.

http://redtape.msnbc.com/2008/08/could-a-hacker.html

I have been recently working inside one of the larger Banks in Australia.
Through this work I have been looking at the controls and mechanisms surrounding the processing of credit and debit cards around the Asia Pacific.

I get perform many security architecture and payment systems assessments.
Gennem årene har jeg altid betragtet beskyttelsen af kortet data som en af de vigtigste overvejelser.

Indtil i går havde jeg aldrig set en CVV eller PVV dekryptering værktøjer. I think some scripted use of these tools could be very interesting.
The site hziggurat29.com

Many of the other tools on this site are also very unique and worth a look.
Big thanks to ziggurat29 for providing such awesome tools.

As many of these sites are of this nature are difficult to find and often seem to vanish over the years, I have chosen to replicate the the text from this page and provide local copies on the files.
It is worth periodically visiting the ziggurat29 site every now and again to see if any additional tools have been posted.

One of the more extraordinary files is the Atalla Hardware Security Module (HSM)  and BogoAtalla for Linksys emulation (simulation) tools. So I wonder if Eracom and Thales are shaking in their boots. Some how I don't think so. ;-)

——– ziggurat29 Text ———

These are all Windows command-line utilities (except where noted); execute with the -help option
at afgøre brug.

DUKPT Decrypt (<- the actual file to download)

This is a utility that will decrypt Encrypted PIN Blocks that have been produced via the DUKPT triple-DES method.  I used this for testing the output of some PIN Pad software I had created, but is also handy for other debugging purposes.

VISA PVV Calculator (<- the actual
file to download)

This is a utility that will compute and verify PIN Verification Values that have been produced using the VISA PVV technique.  It has a bunch of auxiliary functions, such as verifying and fixing a PAN (Luhn computations), creating and encrypting PIN blocks, decrypting and extracting PINs from encrypted PIN blocks, etc.

VISA CVV Calculator (<- den faktiske fil til download)

This is a utility that will compute Card Verification Values that have been produced using the VISA CVV technique.  MasterCard CVC uses the CVV algorithm, so it will work for that as well.  It will compute CVV, CVV2, CVV3, iCVV, CAVV, since these are just variations on service code and the
format of the expiration date.  Verification is simply comparing the computed value with what you have received, so there is no explicit verification function.

Atalla AKB Calculator (<- the actual file to download)

This is a utility that will both generate and decrypt Atalla AKB cryptograms.  You will need the plaintext MFK to perform these operations.  When decrypting, the MAC will also be checked and the results shown.

BogoAtalla (<- the actual file to
download)

This is an Atalla emulator (or simulator).  This software emulation (simulation) of the well-known Atalla Hardware Security Module (HSM) that is used by banks and processors for cryptographic operations, such as verifying/translating PIN blocks, authorising transactions by verifying
CVV / CSC numre, og udfører nøgleudveksling procedurer, blev fremstillet til testformål. Gennemførelsen er ikke den komplette HP Atalla kommando sæt, men snarere blot
portioner, at jeg selv brug for. Når det er sagt, er det fuldstændig nok, hvis du udfører erhverve og / eller udstedelse behandling funktioner, og bruger mere moderne ordninger såsom Visa PVV og DUKPT, og behovet for at gøre generation, kontrol og oversættelse.

This runs as a listening socket server and handles the native Atalla command set.  I have taken some liberties with the error return values and have not striven for high-fidelity there (ie, you may get a different error response from native hardware), but definitely should get identical positive
responses.  Some features implemented here would normally require purchasing premium commands, but all commands here implemented are available.  Examples are generating PVV values and encrypting/decrypting plaintext PIN values.

BogoAtalla for Linksys (<- the actual file to download)

Dette er den Atalla emulator porteret til Linux og bygge til montering på en OpenWRT system. Gør en rigtig billig ($ 60 USD) udvikling / test enhed.

Local Files

bogoatalla002
atallaakbcalc
bogoatalla_10-1_mipsel
dukptdecrypt
visacvvcalc
visapvvcalc

Acquiring Institution
The Financial Institution which holds the Merchant Account partaking in a financial transaction, typically the first bank involved in the processing of a payment.

Applet
A small computer program which facilitates the performance of particular tasks.

Bandwidth
The capacity of a server to carry or process information. The higher the bandwidth the faster graphics-laden web pages will download.

Browser
Short for Web browser, a software application used to locate and display Web pages. The two most popular browsers are Netscape Navigator and Microsoft Internet Explorer. Both of these are graphical browsers, which means that they can display graphics as well as text. In addition, most modern browsers can present multimedia information, including sound and video, though they require plug-ins for some formats.

Caching
The automatic copying and storage of frequently used information onto a computer system – Typically caching is seen whilst surfing the internet (graphics, etc.) and used by Internet Services Providers (ISP’s) to reduce the amount of data requested from the user onto the internet.

Issuer
The Financial Institution which issued the cardholder's account and card.

Cardholder
The individual participating in the financial transaction whose card is being credited or debited.

Card Verification Data
The additional information printed on the card to be processed. This is used to verify if the card was present when the transaction was initiated.  This is the additional digits imprinted on the card usually on the reverse side for VISA & Mastercard and on the front for AMEX.

Certificate
An x.509 certificate used to authenticate entities such as Merchants and Payment Gateways. Certificates can be used to identify and/or encrypt sensitive data such as card numbers and personal cardholder information.

CGI
Common Gateway Interface: A protocol that allows a Web page to run a program on a Web server. Forms, counters, and guest books are common examples of CGI programs.

Any piece of software can be a CGI program if it handles input and output according to the CGI standard. Usually a CGI program is a small program that takes data from a web server and does something with it, like putting the content of a form into an e-mail message, or turning the data into a database query. CGI “scripts” are just scripts which use CGI. CGI is often confused with Perl, which is a programming language, while CGI is an interface to the server from a particular program.

Client
A computer or software that requests a service of another computer system or process (a “server”). For example, a workstation requesting the contents of a file from a file server is a client of the file server. A web browser is commonly referred to as a client.

Clients and Servers
In general, all of the machines on the Internet can be categorised as two types: servers and clients. Those machines that provide services (like Web servers or FTP servers) to other machines are servers. And the machines that are used to connect to those services are clients.

When you connect to Yahoo at www.google.com to read a page, Google is providing a machine (probably a cluster of very large machines), for use on the Internet, to service your request. Google is providing a server. Your machine, on the other hand, is probably providing no services to anyone else on the Internet. Therefore, it is a user machine, also known as a client. It is possible and common for a machine to be both a server and a client !

Cookie
A file sent by some web servers to your computer's hard drive to enable you to quickly and easily return to particular sites. Cookies give rise to privacy concerns as they are often used to store information used for marketing purposes.

The main purpose of cookies is to identify users and possibly prepare customised Web pages for them. When you enter a Web site using cookies, you may be asked to fill out a form providing such information as your name and interests. This information is packaged into a cookie and sent to your Web browser which stores it for later use. The next time you go to the same Web site, your browser will send the cookie to the Web server. The server can use this information to present you with custom Web pages. So, for example, instead of seeing just a generic welcome page you might see a welcome page with your name on it.

CRN
The Customer Receipt Number (CRN) is used to assist the card holder, the payment gateway and the transaction acquirer to confirm the transaction has been processed and to track the transaction throughout the end-to-end transaction process. This is often used when making enquiries about a transaction or for transaction tracking.

Cybersquatting
Bad faith, abusive domain name registration. Cybersquatters register company and product names as domain names with a view to selling them at inflated prices to the “rightful†owners.

/CVC
The additional information printed on the card to be processed. This is used to verify if the card was present when the transaction was initiated.  This is the additional digits imprinted on the card usually on the reverse side for VISA & Mastercard and on the front for AMEX.

Database
A collection of data: part numbers, product codes, customer information, etc. It usually refers to data organised and stored on a computer that can be searched and retrieved by a computer program.

Deep link
A hypertext link directly to a web page, often bypassing home pages or other identifying pages.

Digital Certificate
A pop up window that allows you to identify the level of encryption used to secure a particular web site.

Digital Signature
A complex numeric “signature” designed to be used, in conjunction with special software, to authenticate the sender of a message and guarantee that the contents of the message have not been altered during transmission to the recipient. The EU has adopted legislation which makes electronic signatures legally valid. The Electronic Transaction Bill (Cth) 1999 has the same effect in Australia.

Domain Name
The plain English name given to a host destination on the Internet, for example, www.madrock.net. The suffix, dot.com is known as the generic top level domain, the prefix madrock. The domain name forms part of the Internet Address or URL.

A name that identifies one or more IP addresses. For example, the domain name microsoft.com represents about a dozen IP addresses. Domain names are used in URLs to identify particular Web pages. For example, in the URL http://www.madrock.net, the domain name is madrock.net.

Download
To transfer information from one computer to your computer.

Dynamic web page
A web document that is created from a database in real-time or “on the fly” at the same time it is being viewed, providing a continuous flow of new information and giving visitors a new experience each time they visit the web site.

Dynamic web sites offer the user the ability to interact with the web site. This interaction can take place in the form of a search for products, a questionnaire that automatically posts results or online polls. Basically, dynamic web pages and content are generated from the input of the user.

EC
Electronic Commerce.

Often referred to as simply e-commerce, business that is conducted over the Internet using any of the applications that rely on the Internet, such as e-mail, instant messaging, shopping carts, Web services, and FTP, among others. Electronic commerce can be between two businesses transmitting funds, goods, services and/or data or between a business and a customer.

ECI
The Electronic Commerce Indicator (ECI), is used to determine the source of the original transaction request. This is a program that the banks have developed and have mandated it’s use.

Electronic Data Interchange (EDI)
Systems set up by businesses, which facilitate the electronic exchange of information.

Kryptering
The process of scrambling data to prevent it being viewed by unauthorized persons.

Expiry Date
The date printed on the card indicating when the card will expire. Not to be confused with the card issue date found on some cards.

Firewall
An electronic security barrier and/or traffic filter.

Forms
Forms are web pages comprised of text and “fields” for a user to fill in with information. They are an excellent way of collecting and processing information from people visiting a web site, as well as allowing them to interact with web pages. Forms are written in HTML and processed by CGI programs.

Frame
A means of dividing a web screen into a number of compartments. Frames may give rise to legal disputes if web sites created by third parties are framed as your own.

FTP servers
One of the oldest of the Internet services, File Transfer Protocol makes it possible to move one or more files securely between computers while providing file security and organisation as well as transfer control.

Fulfilment
1. Process of supplying goods after an order has been received.
2. Process of reacting to a customer's request, covering everything that has to happen from the time the customer places an order until they are completely satisfied.

Host
Any computer on a network that provides services or information to other computers on the network. A host is also called a server.

Integration
The software and/or business processes which combine the Merchant's (website, back office, etc.) order processing system with the EFT Network Electronic Payment System.

IP address
Every computer connected to the Internet is assigned a unique number known as an Internet Protocol (IP) address. Since these numbers are usually assigned in country-based blocks, an IP address can often be used to identify the country from which a computer is connecting to the Internet.

Gateway
A system allowing incompatible computer networks to send and receive information.

HTML (Hypertext Markup Language)
Language used to translate text documents into a form which can be sent over the web.

Hyperlink
A highlighted phrase in a document which permits linking to another document or part of a document.

Internet Content Host (ICH)
Those who host or propose to host content on the Internet. Anybody who is responsible for a web site, news group or bulletin board that contains articles, graphics or other internet content provided by others. The host may/may not also produce their own content and/or provide access to the Internet through a carriage service, ie they may also be an ISP.

Internet Service Provider (ISP)
A company that provides an Internet connection through some kind of Internet carriage service, for example Sprint, Chello Broadband, Telstra Bigpond, Adam Internet, Internode. ISP's may/may not also be ICHs.

Mail servers
Almost as ubiquitous and crucial as Web servers, mail servers move and store mail over corporate networks (via LANs and WANs) and across the Internet.

Merchant account
This is an account set up with a bank to process credit card orders from customers.

Merchant
The entity receiving payments for goods and/or services.

Merchant Account
The merchant's account into which transactions are credited or debited.

Merchant Server
The software installed on the Merchant's web sites or back office system to enable real-time or batched processing of financial transactions.

Merchant Server Administrator
The individual(s) responsible for the maintenance of the Merchant Server, including issuing and importing merchant certificates.

MTL
Merchant Transaction Layer (MTL)

PAN
Primary Account Number (PAN) is the number printed on the customers card to reference the cardholder's financial account. This is typically the card number.

Payment Gateway
The Payment Gateway provides a central point of contact/transaction switching with the banking network for the Merchant Server software or devices. The EFT Networks Payment gateway provides advanced integrated reporting, merchant integration services (Mainframe, Mini, Windows, UNIX, OS400, Desktop/Server, EFT PoS Terminals. Loyalty systems, etc.) and Merchant/Bank customised solutions not offered by regional or global banking institutions.

An online system for real-time charging of credit cards when a customer places an order. Normally requires a merchant account.

A common question from merchants is “Do we have to change banks to use payment gateways?”

The answer is NO!  – All you need to do is open a merchant facility with one of the supported banks, EFT Networks can ensure you open the correct one for your transaction needs. The merchant facility is then linked to a nominated bank account for example: Bank of New Zealand, ANZ, St George Bank, NAB, Commonwealth, Westpac, Bank of America, Bank of Scotland, Barclay's, Bank of Queensland, etc. The money is then transferred at the end of each day from your merchant account to your nominated account.

“Pretty Good Privacy”
A type of encryption program used to scramble data.

Portal
A site that gathers together many sites under a common branding, for example, Yahoo and Excite.

Private key
The password which permits information to be decoded in a public key encryption system.

Public key
The password which is used to send a secure message in a public key encryption system.

Secure Certificate
A document that is used to certify that a user or organisation is who they say they are. They contain information about who it belongs to, who it was issued by, expiry date and information that can be used to check out the contents of the certificate. It is as an important part of the SSL system for establishing secure connections.

Server
A computer that provides a service to other computers (known as clients) on a network.

Shopping cart
A shopping cart is a piece of software that acts as an online store's catalogue and ordering process. Typically, a shopping cart is the interface between a company's Web site and its deeper infrastructure, allowing consumers to select merchandise; review what they have selected; make necessary modifications or additions; and purchase the merchandise.

Shopping carts can be sold as independent pieces of software so companies can integrate them into their own unique online solution, or they can be offered as a feature from a service that will create and host a company's e-commerce site.

Spam
The use of email or newsgroups to send unsolicited information.

SSL
Short for Secure Sockets Layer, a protocol developed by Netscape for transmitting private documents via the Internet. SSL works by using a private key to encrypt data that's transferred over the SSL connection. Both Netscape Navigator and Internet Explorer support SSL, and many Web sites use the protocol to obtain confidential user information, such as credit card numbers. By convention, URLs that require an SSL connection start with https: instead of http:.

Letting your customers know that you have SSL protection gives your site credibility and may encourage customers to deal with you in confidence.

A security protocol used to protect information – typically used between the cardholder's web browser and the merchant's webserver and throughout the transaction processing process. 128bit SSL is typical used as a minimum level within the Payment & Financial industries.

A Secure Server uses an SSL certificate. It is generally a piece of web space that can only be dealt with by using SSL ensuring that data transferred between the web space and the browser is encrypted.

Static web page
In web site terms, static means web pages that are not interactive. Because the web site visitor does not have any control over the information provided, the pages and information do not change with each visit. There is not a two-way communication between the user (client) and the web site (server) in a static page.

Uniform Resource Locator (URL)
An Internet address.

Web page
A specific group of related files on the web, which is usually viewed as a single document.

Web servers
At its core, a Web server serves static content to a Web browser by loading a file from a hard disk and serving it across the network to a user's Web browser. This entire exchange is mediated by the browser and server talking to each other using HTTP.

Web site
A collection of web pages stored on a file server.

Guardian Technology Pages
28 September 2006
The Guardian

“Your card has been declined.”
“What? No way, there's plenty of money in that account!”
“I'm sorry, madam, but it's refusing the transaction.”
“It's your card reader, that card worked fine in Boots five minutes ago.”
“The card has been declined. Do you have another one?”
The casual eavesdropper might infer that I – the protesting woman in that dialogue – am financially irresponsible, that my credit card is maxed out or my debit card has reached its overdraft limit. In fact, it's far more likely that the reader on the chip and pin machine is throwing a strop. There is a machine at WH Smith in North End Road, Fulham, that hates my debit card and never accepts it. I've given up trying there. But it's not the only one.
Self-service machines have sprung up everywhere, sprouting card readers and keypads. But watch closely and you will find that more often than not, there is an angry person muttering and swearing at the machine while a queue forms. Watch a little longer and you'll see that queue evaporate – and reform at the counter in front of a human being.
This happened to me and my partner in France recently when we pulled into a petrol station in Epernay. In our desperation, we pulled up at an empty pump, wondering vaguely why it had no queue while others did.
Hvorfor? Because before it would dispense petrol, it wanted a credit card and pin. We fed it mine and I keyed in the number, only for it to be spat out with terrifying admonitions in French about the card being refused. I wiped the strip and tried again. Same reaction, causing a moment's panic: we'd spent a bit on that card – did my bank think it was stolen? Was it blocked?
So we tried my partner's card. Same thing. And then the penny dropped that the pumps with the queues were the old-fashioned ones where you fill the car up and then pay at the till. Clearly the locals knew all about these pumps.
Mind you, it was a miracle we got to France at all. When we arrived at the Eurotunnel terminus we joined a queue of cars for the automatic check-in. I am not the most patient of queuers and within a short time I was railing about how slowly it was moving. A man in a bright yellow jacket was buzzing about from car to car. Finally we got to the head of the queue and fed in the card that was used to book the shuttle online.
It didn't want to know. It spat the card out. We tried again and got as far as tapping in our reservation number. It spat it out again. The chap in the high-visibility jacket buzzed over to us and rolled his eyes, saying: “It's been playing up all day.” He went into the booth with the card – and then we heard him saying over his radio that the whole system had gone down in protest.
As an idea, the technology is great. In practice, we have a long way to go before we can dispense with human beings who can override systems when good card readers go bad. Kate Bevan

© Copyright 2006. The Guardian. Alle rettigheder forbeholdt.

27 September 2006
Kommersant International

The New System will be Offered to 20 Banks<br>Yesterday, at a press conference dedicated to the five-millionth visa card issued by Sberbank, Visa International representative Oliver Hughes announced that a project introducing a system of card-to-card money transfers in Russia has launched its third stage. The project, called Visa Money Transfer (VMT), is now being tested in six Russian banks. Also yesterday, Rosbank announced its intention to participate in the trial. Twenty credit organizations have expressed interest in joining the program, of which ten will be included in the project within the next year. The trial phase of the program will last another six months, after which the VMT system is expected to be unveiled in its full form. The VMT system allows any Visa cardholder to electronically transfer or receive funds to or from another Visa cardholder via an ATM transaction. To make the transaction, all that is needed is the other cardholder's card number. Though the company “at this point is not positioning the new service as an alternative to the system of traditional money transfers,” VMT promises to be competition for that system. The only restriction is that the laws of the Russian Federation permit such transfers to be made in Russia only in rubles. Market analysts believe that the success of the system will depend on Visa's commission policies. Bank commissions for transfers stand at around 1%, and if Visa's commission is more than 0.5%, it is predicted that banks will find it hard to do business within the project. According to some sources, the commission earned by the bank whose client sends the transfer will be 1% of the transfer sum. The bank whose client receives the money will make $0.48 on each transaction. The commission charged by the payment system will be $0.05 + $1. Many Russian banks have expressed interest in the project, but most for now are observing the program's development from the sidelines, preferring to judge for themselves its power to attract customers. http://www.kommersant.com/photo/75/DAILY/2006/180/KMO_032838_00111_1h_t75.jpg

http://www.kommersant.com/photo/512/DAILY/2006/180/KNN_001535_00046_1m.jpg

http://www.kommersant.com/photo/512/DAILY/2006/180/KMO_073625_00010_1m.jpg

http://www.kommersant.com/photo/512/DAILY/2006/180/KMO_069500_00019_1m.jpg

© 2006 ZAO Kommersant Publishing House. Alle rettigheder forbeholdt. ЗРО ÐšÐ¾Ð¼Ð¼ÐµÑ€Ñ Ð°Ð½Ñ‚ÑŠ. Ð˜Ð·Ð´Ð°Ñ‚ÐµÐ»ÑŒÑ ÐºÐ¸Ð¹ Дом. Ð'Ñ Ðµ права защищены.

Recently I came across a new e-Commerce company called EFT Networks, which seems to have an exciting future in the Global Payments Market.

It looks like they have a good mix of consulting and solution design.

www.eftnetworks.com

Services

Electronic Payment

Designed to enable both credit card and direct debit, EFT Networks electronic payment solutions work effectively across multiple sales channels—including Web, Contact Call Centre, IVR and EFTPOS. Manage your payment processing system in-house or outsource, depending on your business needs.

Global Payments

International commerce requires fully integrated global payment and risk management solutions. Requirements span the gamut of payment acceptance considerations from accepting local payment types, pricing in local currencies and dynamically updating prices with changes in exchange rates (dynamic currency conversion), authorising and settling in multiple currencies, to managing fraud and compliance issues such as tax and export regulations. EFT Networks offers a single interface to the global payment network to handle all of these considerations as your business grows.

ICE – Reporting & Management

EFTA Networks Enterprise Business Center gives you a single, easy-to-use interface for managing and configuring payment processing services.

ICE caters for each area of the payment transaction cycle from authentication, authorisation, settlement, dispute resolution and reconciliation – enabling our clients to reduce transaction costs, eliminate fraud, minimise risk, maximise cash flow and increase profitability.

Integrations

EFT Networks provides flexible and secure payment and risk management integrations in to host and legacy systems as well as industry-leading software.

Using industry standards and protocols, our solutions can be customised to suit your exact business requirements

Produkter

ICE (Intelligent Communications Exchange)

At the core is our Intelligent Communications Exchange (ICE) which enables all known transaction enablers from EFTPOS to eCommerce to be routed directly to a client’s bank without intervention for real time acceptance and authentication.

The EFT Networks ICE operates under a philosophy of total System and Physical redundancy delivering the highest uptime rates possible, whilst the transaction network is protected using Solid State and Application Firewalls on all points of ingress and egress.

Every transaction processed through EFT Networks is encrypted using 128 bit Secure Socket Layer (SSL) encryption and submitted for authorisation through EFT Networks “Secure Virtual Private Network†(SVPN).

Our commitment to security is also reflected in our swift compliance with Card Schemes security initiatives such as VerifiedByVisa and MasterCard SecureCode.

EFT Networks comprehensive suit of online reporting tools combined with daily transaction reports will ensure that our clients always have access to up-to-date management information allowing Business Managers to make quick and well-informed business decisions. The decision making process is simplified even further with the power of daily reports that are customised to be imported into most existing legacy systems.

I have been astounded by the take-up by card holders and the push from the major banks in Australia, for customer to embrace the VISA Debit card instead of the traditional Credit Card.

This, although advantageous to the banks, provides a much higher risk to the card holder, especially if the card is used online or in a location where the card could be skimmed.

The problem and the advantage of the VISA Debit card is that it allows access to your savings account funds via a VISA transaction.

This sounds great in theory, as there is no need to transfer money from your savings account to periodically pay off the credit card.

The problem exists where the VISA debit card is skimmed or stolen and money is withdrawn from the card. These funds are taken directly from the card holder savings account and not credit, therefore this increases the risk to the card holder not being able to pay bills/mortgage/loans/etc.

In the traditional credit world, if the credit card was skimmed or stolen, the dept remains the responsibility and risk of the bank, until the fraudulent transaction is investigated.

With the VISA Debit Card this risk is placed upon the card holder, who is often convinced to get one of these cards through good television marketing, when opening a new account or establishing an off-set loan, with no idea of the associated risks.

I don’t like the increased risks associated with these cards not being explained adequately to the card holders so the card holder can make an educated decision as to where he/she uses the card (internet, phone, periodic utility payments, ISP charges, etc.) p>

This risk assumes that the card holder does not rely on credit only to live and does not have any savings to withdraw, but the banks may not give you a debit card anyway if this is the case.