Financial Transaction Processing
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.
Over the years I have always considered the protection of the card data as one of the key considerations.
Until yesterday I had never seen an CVV or PVV decryption tools. 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
to determine usage.
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 (<- the actual file to 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 numbers, and performing key exchange procedures, was produced for testing purposes. This implementation is not of the complete HP Atalla command set, but rather the just
portions that I myself needed. That being said, it is complete enough if you are performing acquiring and/or issuing processing functions, and are using more modern schemes such as Visa PVV and DUKPT, and need to do generation, verification, and translation.
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 (i.e., 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)
This is the Atalla emulator ported to Linux and build for installation on an OpenWRT system. Makes for a really cheap ($60 USD) development/test device.
Local Files
bogoatalla002
atallaakbcalc
bogoatalla_10-1_mipsel
dukptdecrypt
visacvvcalc
visapvvcalc
Recently
September 24th, 2008 at 8:03 am
Does anyone know if this BogoAtalla supports ZMK’s ( Zone Master Keys)? We have been wanting to use this emulator with our ATM processor. But all the processors we deal with want to use 64 character keys for the HSM to HSM exchange. We built our own scaled down ATM switch based on ISO8583 and we are interfacing with another ATM processor whom happens to use a Postillion ( not that it matters). I believe I understand how to use the LMK or KSK but I cannot determine how to test a Zone Master Key .
October 25th, 2008 at 12:18 pm
yes, it does. A ZMK is a Key Exchange Key (KEK). In Atalla AKB there are a couple ways to set up the KEK depending on what the input key form is. If you are receiving AKB keys, you would perhaps make your ZMK with 1KDNE000 and use command 13. If you are importing non-AKB keys (the more common case), you would use a header like 1PUNN0I0 on your ZMK, with command 11B. Both of these appear to be implemented.
You said a 64 character key, though, so that is a little surprising because single DES is a 16 character key, 2-key TDES is 32 characters, and 3-key TDES is 40 characters. So what is 64?
January 15th, 2009 at 7:32 pm
Can you pls help me how to get iskn and bdk ? cause ive manage to get epb and oviously and the pan.I’ve use dukptdecrypt i want to get a PIN.Pls assits.
May 17th, 2009 at 9:04 am
the IKSN and the BDK are not part of Atalla per se, but are part of your setting up to work with DUKPT PIN Pads. Specifically, the BDK is something you create randomly, like any other key (and this is a very important key). The IKSN is built from an identifier indicating which BDK you are using, and a device serial number generated by your key injection facility. You convey the BDK to the injection facility, along with a prefix for the IKSN, and they attach the serial number and inject the both of them (well, actually they derive an ‘Initial PIN Encryption Key’ and inject that). Sooo…
* you will have the BDK on-hand because you generated it to begin with
* the IKSN is the top 59 bits of the KSN, which gets transmitted to you in each DUKPT transaction
May 17th, 2009 at 9:44 am
Has anybody tried atallaakbcalc? It doesn’t appear to work at all.
May 25th, 2009 at 7:58 am
I use it; it’s a pretty simple tool, actually. When you say ‘it doesn’t work at all’, what part of ‘at all’ are you meaning specifically? If you use the –help option, there are some sample commands.
May 27th, 2009 at 9:20 am
What would be the command to import a two part variant 0 KEK, then the command to be used for decrypting a cyrptograms containing CVV Keys? It appears to be along the lines of the 11B.
May 28th, 2009 at 12:02 am
OK, normally I wouldn’t do this but evidently I have had too much coffee this morning.
You do need command 11b for this scenario.
So you mentioned ‘two component’, then you must then be working from components for your KEK? You will need to build your KEK from the components with the SCA, or you can use the atallaakbcalc tool if this is for testing purposes. You must specify a magic header, though which in this case is 1CDNN0I0. Also, your security policy must include C in the option E0.
Then, you need to concoct the 11b command, with the cvv key cryptogram and the KEK. You will then get your AKB cryptogram of the imported cvv key, and the check digits.
With this you can carry on with CVV operations.
Here is a concrete example:
optE0 contains C
mfk 2ABC3DEF4567018998107645FED3CBA20123456789ABCDEF
kek hdr 1CDNN0I0
kek c1 11111111222222223333333344444444
kek c2 88888888888888888888888888888888
kcvv chk 08D7B4
kcvv cryp 1A79047AE419985DE830024C358E3B4A
(the plaintext kek is 99999999aaaaaaaabbbbbbbbcccccccc, with check digits of 820638, and the plaintext cvv key is 0123456789abcdeffedcba9876543210. you wont have this info normally, of course).
make your KEK with either the real atalla, or the tool
atallaakbcalc –calcakb –mfk 2ABC3DEF4567018998107645FED3CBA20123456789ABCDEF –hdr 1CDNN0I0 –component 11111111222222223333333344444444 –component 88888888888888888888888888888888
1CDNN0I0,C2B3A07827006C490B1BF5A5D0D8B6BBFA470D1386CDB4B9,87CD9133B3E8B593
import the cryptogram with the atalla:
you can see the check digits match, so you’re OK.
May 28th, 2009 at 12:05 am
(the html support hosed the atalla command, which uses angle brackets. Here is the command and the response that got dropped from the message)
<11B#0#1A79047AE419985DE830024C358E3B4A#1CDNN0I0,C2B3A07827006C490B1BF5A5D0D8B6BBFA470D1386CDB4B9,87CD9133B3E8B593#>
<21B#1CDNN000,64A883D036BBEF32BF146E43A1BC6DF0B1264D674A68E267,88D88EA266E7D54F#08D7#>
June 3rd, 2009 at 8:43 am
Unfortunately, It looks like the Atallaakbcalc does not support the component option.
June 3rd, 2009 at 11:37 am
I am testing this in preparation for our A8150 to be delivered.
Is there a download for the atallaakbcalc that supports the -component options that you mentioned? If so, where can I find it?
June 11th, 2009 at 7:29 pm
Dave,
I know that everyone in this forum is very knowledgeable about this subject matter. I would just like to find out one things, where can I get a simple explanation of the Atalla command set that even a lay man can use. Basically I want to be able to effectively communicate with the virtual HSM (Bogo Atalla) and get the out puts that I desire, please help!
June 17th, 2009 at 10:44 am
Hi all,
My question is about the DUKPT key management scheme.
My understanding is that this is the recommended method for securing sensitive data for financial transactions nowadays and is superior to master/session because a different (derived) key is used for each individual transaction.
I’m just wanting to understand how much more secure this method is.
If a hacker were to record transactions for, say, a month by sniffing a network, for example, and then was able to break the key for one of the transacitons – could he then calculate the key for each following transaction if he has knowledge of how the DUKPT key derivation in the terminal works? I’m assuming this knowledge would be available to anyone who has access to the DUKPT standard.
I’m also assuming that it would be next to impossible to calculate the keys for transaction prior to the hacked one because the DUKPT derivation method uses a non-reversible transformation. Does this sound right – any comments would be appreciated – thanks, Colin Cummins
June 22nd, 2009 at 11:52 am
Hi Colin,
I have created a separate post with some materials.
I will elaborate once I get some time.
http://www.madrock.net/2009/06/dukpt-overview-and-transaction-notes/
Thanks
Derek