Using ECH Payloads in PCI-Compliant Processes

Use

This document provides information about using payloads of Error and Conflict Handler (ECH) in processes that comply with the Payment Card Industry Data Security Standard ( PCI-DSS, abbreviated to PCI). For more information, see http://www.pcisecuritystandards.org Information published on non-SAP site

Error and Conflict Handler allows you to encrypt payloads on database level. In other words, you can save the contents in encrypted format. For more information, see Encrypting Payload on Database Level.

ECH provides the technical capabilities for complying with the PCI standard. However, in the current, first implementation of the standard, these requirements are not always met ideally. For example, missing capabilities for masking the primary account number need to be compensated by preventing the display of the payload.

The following table lists in how far several requirements of the PCI standard are met by the ECH payload encryption capabilities and which limitations exist with regard to the standard.

PCI Requirement: Short Description	PCI Requirement	Reassignment and Restrictions in ECH
3.3 Mask Primary Account Number (PAN) when displayed.	3.3 Mask the PAN when displayed (at the most, the first six digits and last four digits can be displayed). Notes: This requirement does not apply to employees and other parties with legitimate business reasons to see the full PAN. This requirement does not replace stricter requirements for the display or cardholder data, for example POS documents.	In payment scenarios, we recommend that ECH customers prevent access to payloads in the Payload Editor. This is because it is common practice to exchange sensitive data in these processes. You can restrict payload access in the Payload Editor by applying special authorizations.
3.4 Always store the PAN in encrypted format	3.4 Make the PAN unreadable wherever it is stored (including portable, digital media, backup media, and in logs). To do so, use one of the following procedures: One-way hashes based on strong cryptography (hash must be created of the entire PAN) Truncation (you cannot use the hash function to replace shortened PAN segments) Index tokens and pads (you must store pads securely) Strong cryptography with corresponding key management processes and procedures	If you activate payload encryption on database level, the entire payload containing the PAN is stored in encrypted format. However, ECH components access the payload in clear text, for example, in retry mode or in the Payload Editor. Note When a payload version is encrypted, the related postprocessing order is not archivable.
3.6.5 Allow removal or replacements of key if the key's integrity is in danger	3.6.5 Removing or replacing keys (for example, with archiving, destruction, or cancellation) based on necessity when the integrity of the key is in danger (for example, the departure of an employee who is familiar with the clear text key and so on), or if you have reason to believe that specific keys have been corrupted.	If a key has been corrupted, the administrator checks whether it can still be used to encrypt messages. For encryption in the ECH payload store, proceed as follows: Run the report `FEHR_CHANGE_ENCRYPTION_KEY` in simulation mode. Based on the result, use the report to change the corrupted key. For more information about the report, see Encrypting and Reassigning Payloads.
10.2 Individual accesses to PAN logs	10.2 Implementing automatic audit trails for all system components for reconstructing the following events: 10.2.1 All individual accesses to cardholder data	All access to payload content is logged in the security audit log of the underlying application server. For more information, see Security-Audit-Log (BC-SEC) (AS_ABAP).