Atalla HSM - TAL

[Robert Hutchings]

I am curious to see if people have experience with Host Security
Modules? What kind of programming is relevant to these devices. I
assume encryption/decryption, but what specifically does a programmer
do? On the Tandem, much of this was written in TAL many years ago AFAIK...

[Warren M]

The Atalla HSMs support probably a couple hundered different commands. Triple DES encrypt/decrypt, various proprietary algorithims, key maqnagement, public key encryption, etc. Some commands are "premium" commands and only available for an extra price. Atalla provides a "boxcar" process that accepts writereads from an application and sends the request over TCP/IP. The response is returned via a normal Guardian reply. In order to deal with the HSM, you have to be familiar with the format of each request and response. These are documented in the Atalla Banking command reference manual (available to Atalla customers).

Beyond that, I'm not sure what information you're looking for.

[wbreidbach]

Am Freitag, 10. Oktober 2014 01:59:02 UTC+2 schrieb Warren M:
> The Atalla HSMs support probably a couple hundered different commands. Triple DES encrypt/decrypt, various proprietary algorithims, key maqnagement, public key encryption, etc. Some commands are "premium" commands and only available for an extra price. Atalla provides a "boxcar" process that accepts writereads from an application and sends the request over TCP/IP. The response is returned via a normal Guardian reply. In order to deal with the HSM, you have to be familiar with the format of each request and response. These are documented in the Atalla Banking command reference manual (available to Atalla customers).
>
>
>
> Beyond that, I'm not sure what information you're looking for.

We are using the DEP box from Banksys (ATOS). The box itself is in fact a PC containing 2 hardware encryption modules which support a bunch of functions. The functionality can be bound into a customized application within the box. The box communicates via TCP/IP.
The main reason for using HSMs is security, all communication to the box is encrypted, the box itself is highly protected against anything, no key is available in clear on the host system.

[Robert Hutchings]

On 10/9/2014 6:59 PM, Warren M wrote:
> The Atalla HSMs support probably a couple hundered different commands. Triple DES encrypt/decrypt, various proprietary algorithims, key maqnagement, public key encryption, etc. Some commands are "premium" commands and only available for an extra price. Atalla provides a "boxcar" process that accepts writereads from an application and sends the request over TCP/IP. The response is returned via a normal Guardian reply. In order to deal with the HSM, you have to be familiar with the format of each request and response. These are documented in the Atalla Banking command reference manual (available to Atalla customers).
>
> Beyond that, I'm not sure what information you're looking for.
>

OK, thanks for that. Let's take a scenario where a retailer is
processing POS transactions using (at some point) an HP NonStop with
Atalla Boxcar. What would a programmer be doing with the Boxcar? I
guess I am having trouble visualizing what a programmer would do with
that boxcar...

[wbreidbach]

I do not have experiences with that Atalla process in the actual version, the only Atalla we used was the 7000 and that has been 15+ years ago. So I can tell you what our DEP-process is doing but there should not be a real difference.
An application program sends a message to the boxcar (DEP) process and receives the appropiate answer. The boxcar process is responsible for the communication with the box(es), it is able to handle lots of messages from lots of processes. So for the application program it should be just a WRITEREAD to the boxcar process.

[Warren M]

On Friday, October 10, 2014 8:51:12 AM UTC-4, Robert Hutchings wrote:
I guess I am having trouble visualizing what a programmer would do with that boxcar...

Boxcar is simply a Guardian writeread to TCP/IP bridge process. An application sends a writeread to the boxcar process, the boxcar process communicates with Atalla HSM via TCP/IP and returns a reply to the application. Think of it like any other Guardian I/O process. request in / response back. Boxcar is of course multi-threaded and can handle may concurrent requests, although in my testing I've found the limit of the current HSMs is about 14 concurrent requests. Beyond that, queuing occurs in boxcar process transparent to the application.

If you're going to be communicating with the HSM, you need to understand the command reference manual I referred to earlier. The command reference manual documents the format of all commands to and responses from the HSM.

This is where it gets complicated. The HSM supports many types of keys: master keys, working keys, communication keys, etc. In addition the HSM supports many types of encryption/decryption that I also mentioned earlier. The combinations of all these keys and encryption modes gets very confusing. You as the programmer have to know what command to send to the HSM under what keys. Once you know that, the command reference will give you the format of the command and the format of the response. At that point, it's a simple writeread from the application to the boxcar process with the properly formatted request.

Of course, if you're dealing with a high availability environment, you need to consider rerouting to an alternate boxcar processes should an HSM fail. It does happen.

[Robert Hutchings]

Thanks Warren. I downloaded a programmer guide for a HSM (not Atalla)
and, wow, there are a LOT of commands and responses!

[Robert Hutchings]

Also, where does the HSM "sit" in the path of a typical POS transaction?
If use my debit card at Walmart and the transaction is routed to PULSE
(for example), does PULSE operate the HSM? Where would the HSM be
physically located?

[Warren M]

For a simple pinned debit transaction, the pin pad at Walmart will encrypt the PIN under a particular key stored in the pin pad. The encrypted pin block is passed along from the pin pad to Walmart's host. Walmart's host then trans-crypts the pin block (decrypt from pin pad key to processors comm key without ever being in the clear). Walmart's processor then trans-crypts the pin block from Walmart's current comm key to Pulse's current comm key, Pulse again trans-crypts the pin block from Pulse's comm key with the acquiring processor to the issuing bank's comm key. The issuing bank then decrypts the PIN block and validates the PIN.

Every one of these trans-cryptions is an HSM interaction. Where the HSM "sits" in the transaction flow depends on the institution (merchant, acquirer, network, issuing bank) and the software that they are running. At no point in this flow is the pin ever in the clear except inside the pin pad and inside the HSM. Even when the pin block reaches the issuing bank, the HSM is sent the encrypted pin block and returns only a good/bad result.

Pulse is a Tandem based network, so the HSM's would be physically attached to their Tandems.

[wbreidbach]

I agree to Warren. just to add a bit more details:
The EPP (Encrypted Pin Pad) at the terminal encrypts the PIN, the messages is secured using a message authentificatin key and is send to the terminal provider. The terminal provider usually reencrypts the meaage within a HSM, creating a new message authentication key. The authorisation system receives this message and verifies the message authentication key first within a HSM. If that is ok the pin is verified within a HSM, usually the system does not store the pin itself but a pin verification value which has been created during pin creation (again a HSM function). The way back to the terminal is again protected by message authentication keys.

[Robert Hutchings]

Wow, that is an excellent explanation! Thanks again.

[Robert Hutchings]

So when, if ever, is the PIN sent "in the clear"? I don't think it is....

[Warren M]

It's in the clear briefly in the pin pad. Once it's been encrypted, the clear pin in the pin pad "should" be overwritten. The pin is technically in the clear inside the HSM during the transcryption processes, but the HSM provides no way to access it. Any atttempt to open the HSM automatically clears all memory in the HSM.