The name Atalla is intimately linked with HSMs. After all, Mohamed Atalla invented the very first hardware security module in 1972. Therefore, it is not surprising that Atalla has also created a way to communicate with HSMs in a very smart way. In this article, we will discuss the Atalla Command Language.
There are several ways that users and other machines can interact with an HSM like the Utimaco Atalla HSM:
- An API (Application Programming Interface);
- A service such as a web service (REST, SOAP…);
- A remote procedure call system;
- A client line interface (CLI);
- A visual interface (GUI) with menus and buttons.
Therefore, in such situations, the users have ways to configure HSM parameters or perform cryptographic operations using menus and fillable forms. However, in the context of an HSM, that technique, besides presenting eventually security issues, is not convenient with complex operations.
The needed GUI would be too complex to be used in a fast and ergonomic way.
Providing the end-user direct programming access (by C, C++ or C# for instance) either via an API, a web service, or an RPC is also not a secure solution because it could create opportunities for attacks, especially with the increased potential for flaws. HSMs are supposed to be ultra-secure.
Therefore, this is not an acceptable solution either.
Atalla developed a text-based command system that is similar to a command shell (e.g. DOS or BASH) with a specific format. It can be considered as a Client Line Interface (CLI). It has an optimal use in the context of interfacing HSMs, including Atalla HSMs.
Overview of the Atalla Command Language
For the average programmer or system engineer, a text-based command system is not something uncommon. Starting in the 70s, a lot of these languages were invented. They were usually used to control industrial devices, especially critical devices as found in the military for example.
Some of the readers may know about the Hayes Command Set modem language. This is a text-based language that is still widely used in telecommunications engineering. Generally, text-based command languages interface the serial port directly. Atalla commands can communicate with the Atalla HSM via its COM ports and over the network as well (Of course, through the secure configuration assistant only).
Atalla HSMs are not provided with a regular operating system and so a regular shell. However, Atalla commands are what we could define as the “Atalla HSM shell” because they allow the user to program the HSMs with different types of scenarios, especially those with cryptographic commands.
Is CLI Better than APIs or GUIs for Interfacing HSMs?
Invented in the 70s, Client Line Interfaces (CLI), which are practically the same as text-based command languages were replaced in the 90s by APIs and SDKs. The typical 70’s computer system was a console-based system. It often had a terminal connected to a central server with an operator and an end-user who accessed the system by typing text commands. There was no other way to access the system except by sending questions (“commands”) and getting answers (“commands responses”).
The APIs, which can be delivered in various formats (static libs, dynamic libraries, .NET assemblies, java jars, etc.), provide a “machine to machine” access and often penetrate “directly” into the runtime of the targeted device. Therefore, APIs may allow the execution of unsecured code, or expose unsecured functions with vulnerabilities including buffer overflows and similar exploits.
Of course, a command shell may also be theoretically subject to the same issues. However, the commands are tokenized, parsed, and have only a limited amount of interpretation contrarily to a programming language such as C or C++. As a result the commands are certainly less prone to vulnerabilities such as Buffers Overflow than a full programming language could be.
Under the hood, a web service is a tokenized text command shell that is by nature quite difficult to be directly used by a human. The cons of a command-based language are that the users have to learn it so to be able to use it efficiently. In the case of a highly specialized system such as the Atalla HSM, it is perfectly acceptable to spend time to train the end users in the Atalla Command language.
A command-based language can still be programmed by scripts. For instance, programming languages such as Perl or Python are able to quickly generate batches of commands that will be executed by ATMs or switches that interact with the Atalla HSM are using such batches of commands to implement higher-level functions. They open a socket with the Atalla HSM, generate the commands, and send the commands to the socket and wait for an answer. They can use C or C++ to do that, but they are not using a C or C++ API.
Overview of the Commands
There are more than 200 commands in the Atalla Command language. This makes the command shell quite a complex language already. Anything that is needed to interface payment networks, ATMs, and EFTs, among others, is present in the command set.
Users communicate with the Atalla HSM via the secure Configuration Assistant (SCA), a hardware system that authenticates users via smartcards and let them interface the HSM.
The sending of direct commands to the Atalla HSM via the SCA is presented in the following picture.
For example, note that the SCA implements a visual user interface to help the end-user generate or verify cryptograms. Under the hood, these are Atalla commands that were sent.
The commands have different levels of security policy:
- Standard commands that do not represent a risk in terms of security exposures, usually these are “global purposes” functions
- Security exposure commands that may represent a risk, so they are disabled by default
- Custom commands are customer specific proprietary commands and can be activated only by a special license
In terms of functionalities, the commands are divided in two groups:
- Utility commands, consisting mainly in general operations, configurations, and diagnostics;
- Cryptographic commands, consisting in operations involving encryption, decryption, key generation, etc.
Formatting of the Commands
Atalla commands are text based and tokenized, meaning that the different parameters they carry are identified by separators ‘tokens’ which are special reserved symbols.
The commands follow a special syntax (or grammar) as follows:
A command will look as a text data separated by the starting tag ‘<’ and the closing tag ‘>’ :
The _CMD_ID_ value is a number representing the number of the command (ex: ‘105’ )
The _FIELD1_,_FIELD2_,...,_FIELDN_ are the values of the N parameters of the command
The _CONTEXT_TAG_ value is a 5,000 word maximum data field, optional and which can have various usages.
All the parameters are separated by the token ‘#’.
An answer to the command will have the same format as the command, which means that several values may be returned in the answer.
We note here that there is no mechanism to know from which command the answer is based, except the network mechanisms itself. In other terms, Atalla commands are not implemented as a messaging service. By default, they do not contain anything like a message ID and a checksum or a MAC. Anyway, such data could be included in the context field. Nevertheless, TCP/IP and TLS protocols already involves such messaging features. Therefore, it may probably not be needed to replicate them.
Input commands have odd-numbered first digits; the first digit of the corresponding response is a digit higher. For example, if 10 is the command ID, 20 is the response ID, if 37B is the command ID, 47B is the response ID.
Example of a command and response:
74C,7CA7039EDE2AB473#^Generate KPE for ATM 325#>
9F,66FE4A998CB954DF#DE9D#^Generate KPE for ATM 325#>CRLF
Atalla’s utility commands do not require the loading of a master key file into the HSM.. They allow read only access to system information like CPU and the battery status. Generally, these commands can be used for the HSM configuration, changing security policies, and running several self-check tests under dual control implemented via smartcards and SCA.
Atalla’s cryptographic commands are the most important group of commands. They allow banking operations to be processed in the context of the financial interchange networks. Note that while this is a text-based command language, several parameters represent binary data in hexadecimal mode, same as the “APDU” protocol in smart cards. Cryptographic commands include:
The DES commands offer what is needed to manage triple DES keys.
They generate PIN Encryption Keys for use with payment security processors. They also generate MAC or Data Encryption keys. Additionally, they can translate, import keys, load keys/change keys in various models of ATMs.
Remote Key Loading (RKL) Commands
These commands utilize RSA keys for initializing remote devices. These commands generate RSA key pairs, import public keys, generate message digests, encrypt an ATM Master key using the public key stored in the EPP (Electronic PIN Pad), and generate and verify digital signatures.
These commands will encrypt, generate, translate, and verify PINs for different PIN blocks formats such as Identikey, IBM 3624 VISA, Diebold, Atalla, and NCR. They can also convert to and from such formats.
Transaction and Authorization Data-Related Commands and Other EMV Commands
These commands are general purpose cryptographic functions for encrypting and decrypting data. They also includes DUKPT-related commands such as the generation and verification of MAC. They also can generate and verify credit and debit authorization codes. Additionally, they will generate and verify Authorization Request Cryptograms (ARQC), generate message authentication codes, and generate and verify VCSC signatures. Finally, they can verify credit cards’ CVV, CSC, CVV3, etc.
The Atalla command language is a secure and efficient way to communicate with the Atalla HSM. It contains everything that is needed to perform banking operations in financial networks. One day it may become a standard in how to interface HSMs in general. Potentially, it could then be used in the future in HSMs from other vendors.
- More articles on the AT1000 (2018 - today), by Martin Rupp and the Utimaco team.