This section of the Reference document guides you through secure and efficient application development practices for the StrongAuth KeyAppliance (SAKA). You must have reviewed Chapter 1 of this document to understand the basic architecture of the SAKA before continuing with this section.

While programming languages vary, and platforms/frameworks differ in what they provide an applicationdeveloper to optimize code, this section will focus on generic guidelines rather than platform or framework-specific guidelines. Developers are free to choose strategies for improving on these recommendations.

While the SAKA can encrypt and store anything to a limit of 10,000 characters, the primary use at most customer sites is for the protection and storage of cardholder data (CHD) in e-commerce environments for compliance to Payment Card Industry Data Security Standard (PCI-DSS). As such, this section will refer to CHD in discussing these guidelines; however, the same principles apply to any sensitive data protected by the SAKA: social security numbers (SSN), bank account numbers (BAN), birth-dates, other personally identifiable information (PII), etc. It is worth mentioning, that when used in conjunction with the SAKA, the StrongKey CryptoEngine (SKCE) - a free and open-source tool to protect files of any-type- any-size (http://sourceforge.net/projects/skce) - escrows base64-encoded symmetric cryptographic keys as sensitive objects. Some customers have also chosen to protect Secure Socket Layer (SSL) keys/certificates on the SAKA.

This document refers to the following diagram to discuss development guidelines. While not every site will be configured similarly, most will abstract to the pattern shown below.

 In this sample SAKA configuration, the site has:

• A web-tier in the demilitarized zone (DMZ), receiving customer transactions from the internet;
• An application tier with servers and application databases (ADB) that represent the business logic and data;
• A PCI zone containing the SAKA appliances and its internal database (IDB). The SAKA not only offers encryption, tokenization and key-management services for protecting sensitive data, but with the Card Crypto Service (CCS) module, it also offers transaction decryption using the Derived Unique Key Per Transaction (DUKPT) algorithm conforming to the American National Standards Institute (ANSI) X9.24-1 – 2009 standard. “Card present” transactions are processed by the CCS module, while “card not present” transactions are handled by the “ foundation” modules of the SAKA – modules that perform encryption, decryption, tokenization, etc.;
• A Virtual Private Network (VPN) that allows Key Custodians (KC) to authorize the use of the SAKA from remote locations, and for Operations staff to enable/authorize applications to call webservices on the SAKA; and
• Three payment gateways: i) PG1, which offers a Hypertext Transfer Protocol (HTTP) and Simple Object Access Protocol (SOAP) interface to their transaction gateway, ii) PG2, which only offers an HTTP interface and iii) PG3, which only offers a SOAP interface.

Since all transactions received in the web-tier will be encrypted using Transport Layer Security (TLS) (DUKPT transactions will have been encrypted twice: i) once when encrypted by the card-reader at the point-of-sale (POS) terminal, and ii) at the TLS layer of the network connection) there is no need for expensive VPNs; the general internet provides adequate connectivity while the cryptographic schemes provide the data-protection.