Secure start-up for POS

Secure start-up of encryption services in a typical retail POS configuration can be provided by implementing the following (very general) best practices.

Each Local Security (Encryption) Service should be locked upon start-up. While locked, all sensitive data is encrypted and presumably safely stored. During the Local Security Service start-up procedure the application is unlocked so that it can get on with its business processing functions. Unlocking can occur through an automated or manual process – the latter is invoked in situations where the retail WAN connectivity is unavailable for some reason (if WAN connectivity is used).

The security of this process depends on the secrecy of the unlock keys, which are unique to each retail site and should only be used once. Under the automatic unlocking process, the unlock key is discarded after use (and presumably wiped from memory) and then a new unlock key is automatically rotated in via the Security Administration Service, thereby greatly reducing the exposure of the unlock key.

The manual unlock process, on the other hand, exposes a valid unlock key to at least two people – a central help-desk support person and a system administrator at the respective retail site (or similar).

Although the key is rotated after use, a maliciously cloned Local Security Service environment could still be unlocked using that unlock key if the cloned system remains off-line. This could enable an attacker to invoke and unlock a cloned Local Security Service in a safe environment and potentially use the data and processes on the Local Security Service to decrypt cached/archived credit card data. The impact of a successful breach of this process could be extreme. Customer data for several years could be compromised, resulting in customer identity theft, retail reputation tarnishing, etc.

This situation is acknowledged in a typical POS architecture and can be addressed by asymmetric keys or compartmentalization of symmetric encryption keys to limit the amount of data that is accessible by each encryption key. If this is not implemented, it could be possible for an attacker, through social engineering, to get the unlock secret from Central Help-desk, and then use this to attack the system.

Note that this authentication cannot be done by POS itself – it must be an out-of-band mechanism. It is vital that a robust business process complete with adequate checks and balances, be instituted at every retail site that will run a Local Security Service.

Additional technologies could be deployed to further protect this vital aspect of the Local Security Service’s operation, such as smart cards. A smartcard based identification, authentication, and authorization mechanism should be a significant improvement in protecting the startup and unlock process for each Local Security Service.

However, such measures in many cases would not be feasible to deploy at each retail location. As such, a process as mentioned above is even more important to address carefully. In numerous industries, mission critical applications commonly leverage technologies such as smart cards, one time passwords, and others for protecting such vital operating states as unlocking the Local Security Service. The unlock keys should be available in different formats in automatic mode and in response to a request to the Central Helpdesk.

The same key is not used in both cases. The whole path in the automatic case must be protected. Since the key may be requested from the Helpdesk, the Helpdesk should not have complete knowledge of a single key for one store and the keys should be different across different stores. Please review this page for additional discussion about this topic.