ICVerify: encrypt request and answer files using EncryptionManager

To increase the security when dealing with credit card processing via ICVerify’s request/answer methodology, it is possible to encrypt and decrypt this information. However, the documentation is fairly sketchy on this subject, especially when you’re not working in one of the languages used in the examples in the SDK.

After some hair-pulling on why it doesn’t work, I think I’ve got it figured out now. Here are the steps I used to get it working:

  1. EncryptionManager.DLL is not a normal DLL, it is a .NET assembly. Trying to register it with regsrv32 will result in an error message, saying that it doesn’t have a DLLRegisterServer entry point. The trick is to use either the .NET gacutl.exe or the icvgacutil.exe supplied on the ICVerify SDK CD.
    UPDATE:You also have to use regasm to register the assembly!
  2. Once registered at the Global Assembly Cache (GAC), the name of the DLL is not EncryptionManager. To make things more interesting, I had to link to the name FirstData.Encryption.Facade.EncryptionManager. The only way to figure this out is to dig through the registry after registering the DLL, or to use the option on the GAC utility to write out a registry modification file.
  3. In Progress, you can use the COM viewer to access EncryptionManager.tlb, and see the different methods defined in the DLL. You’re only going to be using 2 of them most likely: EncryptThirdPartyMessage and DecryptThirdPartyMessage. Both use the creation date of the file you’re working with, so be careful not to copy this file or move it across file systems.
The Progress code I used to encrypt a request file is as follows:

DEFINE VARIABLE vhEncryption AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE vcPrepFilename AS CHARACTER NO-UNDO

INITIAL “C:TEMPicver001.prep”.

DEFINE VARIABLE vcReqFilename AS CHARACTER NO-UNDO

INITIAL “C:TEMPicver001.req”.

DEFINE VARIABLE vcEncrypted AS CHARACTER NO-UNDO.
DEFINE VARIABLE vcRequest AS CHARACTER NO-UNDO.
DEFINE STREAM sOutput.

UPDATE vcRequest FORMAT “x(60)”.
CREATE “FirstData.Encryption.Facade.EncryptionManager” vhEncryption.
OUTPUT STREAM sOutput TO VALUE(vcPrepFilename).
vcEncrypted = vhEncryption:EncryptThirdPartyMessage(vcPrepFilename,vcRequest).
PUT STREAM sOutput UNFORMATTED vcEncrypted.
OUTPUT STREAM sOutput CLOSE.
OS-RENAME VALUE(vcPrepFilename) VALUE(vcReqFilename).

The decryption routine is somewhat simpler, since we don’t have to move files around so much:

DEFINE VARIABLE vhEncryption     AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE vcAnswerFilename AS CHARACTER NO-UNDO

INITIAL “C:TEMPicver001.ans”.

DEFINE VARIABLE vcEncrypted AS CHARACTER NO-UNDO.
DEFINE VARIABLE vcDecrypted AS CHARACTER NO-UNDO.
DEFINE STREAM sInput.

CREATE “FirstData.Encryption.Facade.EncryptionManager” vhEncryption.
INPUT STREAM sInput FROM VALUE(vcAnswerFilename).
IMPORT STREAM sInput UNFORMATTED vcEncrypted.
vcDecrypted = vhEncryption:DecryptThirdPartyMessage(vcAnswerFilename,vcEncrypted).
INPUT STREAM sInput CLOSE.

These code snippets should have some more error checking. Also, the request can be more than one line, depending on the version of ICVerify and the answer file settings in the configuration.

7 Replies to “ICVerify: encrypt request and answer files using EncryptionManager”

  1. Hey Ronald, interesting article.. and right where I am mired down 😉 I have an issue with “third party” ICV Requests and need to get more info on teh encryption / dycryption. In particular, I need to figure out why ICVerify GUI works with CVV2, btu request files dont.

    The SDK is no help here, and the ICVGui requests are …. encrypted.. so I cant even check them to see what is up with that.

    By Any chance, do you have a working request viewer (or code that I can get from you that is close) ? If I can figure out the formatting they are using, I might get this pos working.

    Thanks.
    Charles…

  2. Hey Charles,

    Sorry, the only example I have is the code above. It was hard enough to get that going… 🙂

    Good luck, and let me know if you get it working on your platform!

    Cheers,

    Ronald.

  3. Ronald,

    Though I am not a Progress guy, this was very helpful. One thing of note. This technique failed on ICVerify 4.04 returning “NINVALID REQUEST: REQUEST IS NOT ENCRYPTED”. It seems that on the encrypt you now must pass the “request file name”, not the temporary file name “even if that file has not been created” (that according to tech support). Of course the file cannot be extant as you risk ICVerify Multiuser grabbing it before you are done with it. Once I made that change all was well. Just thought I’d pass this along.

    Regards,
    Michael

  4. Hi Michael,

    That’s interesting… since one change I had to make is to use OS-RENAME versus a more elaborate renaming routine, because the creation date of the file was used in the encryption process. So with 4.04 I guess they no longer use the creation date, since support stated that the file doesn’t have to be created.

    we haven’t upgraded to 4.04 yet, but I’ll keep this in the back of my mind. Thanks!!

  5. This is how you get ICVerify’s (a tremendously bad piece of software) encryption client and server working:

    1) Make sure the “ICVTnsServer” service is running on your server (or local machine if using that as your server).
    2) Open port 11000 on your server where the above service is running.
    3) To simplify life, put EncryptionManager.dll and ICVTnsClient.dll in your windowssystem32 directory.
    4) Locate regasm on your PC. Use whatever the latest version is that you find. It’s part of any .NET installation.
    5) regasm windowssystem32ICVTnsClient.dll /tlb
    6) regasm windowssystem32ICVTnsClient.dll /codebase (may not be necessary – I’m not sure)
    7) regasm windowssystem32EncryptionManager.dll /tlb (may not be necessary – I’m not sure)
    8) regasm windowssystem32EncryptionManager.dll /codebase (may not be necessary – I’m not sure)
    9) On your client machine (or the server if you’re using the same machine for both) copy ICVTnsClient.dll.config from the SDK installation directory to windowssystem32, and change this:

    ‘add key=”MachineName” value=”whatever they’ve got here” /’

    to this:

    ‘add key=”MachineName” value=”your server’s IP address” /’

    10) Start the “ICVerify Multi User” application on your server (ICVERIFYICWin4xxicvmlt32.exe)

    You’ll now have the service running on your server, the DLL’s properly registered, and their file scanning program running waiting for your program to write transactions and read results.

    As an aside, they store all of their data files in icverifyICWin420DATADIR using the same encryption protocol, so you can easily decode things and write directly to the files manually, if you really want to bypass their horrid user interface. This is useful if your app wants to know batch totals, or create historical reports, etc. You can pretty much eliminate ICVerify from the any user interaction except for settling at the end of the day.

    1. Holy crap, David! Thanks a bunch!

      I just happened to look at this post again, checking what the exact commands were that I had to use to register the old .DLL (expecting the same issue with the new 4.2 version), and lo and behold – you’ve already done the hard work for the ICVTnsClient!

      Thanks a bunch!

    2. Unfortunately, Progress doesn’t seem to recognize the .dll.config file, no matter where I put it (current directory, system32, OpenEdge bin directory). So I had to punt on this solution, and go with two small VB programs: one that encrypts a local file and puts it in the ICVerify request directory, and one that takes an answer file and decrypts it to a local file. They’re not the prettiest of programs, but I’ll post them on GitHub or CodePlex for other people’s amusement….

Leave a Reply

Your email address will not be published. Required fields are marked *