nets Payment Card Core Software Security Installation Guide

nets Payment Card Core Software Security Installation Guide

VERSION HISTORY

guidance- Retention policy clarified for merchants- Explicitly TLS 1.2- Clarified centralized logging 5.6- Updated Appendix A- Clarified distribution of this document- Updated 5.5 Key Management- Removed SW library versions- Clarify IG distribution process
1.4.1| 2016-01-27| DFo| X.Y. pp and subtitle for the document
1.4.2| 2016-04-05| DFo| Editorial
2.0| 2017-06-29| JRä| Describe how masked PANs are generated Remove text that does not require customer actions Rename Card Svc to Payment Card Core Add Spire and Spica update descriptions Add Payment Frontend description Fix Payment Card Core version to 2.0.xRemove section Cardholder data handling as unnecessary Clarifications related to requirements 2.1, 2.2, 11.1, 11.2Include versioning character set and clarify version numbering component descriptions Terminology correction Poplatek PA → Payment Card Core
2.0.1| 2018-06-11| JRä| Update company: Poplatek Oy → Poplatek Payments Oy
2.2| 2018-10-26| JRä| Update Payment Card Core versionUpdate PAN masking description to match Payment Card Core 2.2.x
2.3| 2019-12-04| JRä| Update Payment Card Core versions Update PTS references for Samoa terminals 5.3.1
3.0| 2021-06-22| JRä| Update Payment Card Core version Update references to PCI DSS and PA-DSS requirements Update samoa updater endpoint Add Castles as terminal vendor Update dependencies 5.3.2Fix typosUpdate document layout
3.1| 2022-06-02| JRä| Update Payment Card Core version Remove the requirement for not to broadcast SSID in 4.2Remove Spire and Worldline terminals from hardware dependencies in 5.3.1 | Remove update descriptions for Spire and Worldline terminals in 5.3.3 |Add MP200 to hardware dependencies in 5.3.1 | Update DNS name for required server in 3 | Add VEGA3000 PTS 6.x to dependencies 5.3.1 |Clarify differences between PAN masking in merchant and cardholder receipts
4.1| 2023-07-05| JRä| Adapted from PCI PA-DSS to PCI SSF Change company name to Nexi Digital Finland Change Secure Software standard version to 1.2.1 Add missing IG related requirements to Appendix A
4.2| 2023-10-13| **** JRä| Change company name to Nexi
4.3| 2023-11-28| JRä| Change Secure Software standard version to 1.2.1 Add missing IG related requirements to Appendix A

INTRODUCTION

The Payment Card Industry Data Security Standard (PCI DSS) [1] specifies requirements for the configu ration, operation andsecurity of payment cards transactions. These requirements apply to organizations that store, process or transmit cardholder information and target to prevent credit card fraud and to increase security.

The PCI Secure Software Requirements [2] are defined to protect the integrity of payment transactions and the confidentiality of all sensitive data stored, processed, or transmitted in association with payment transactions.

The purpose of this Implementation Guide is to instruct Merchants and Resellers how to install and use Nexi Digital Finland (Nexi) payment terminals running Payment Card Core in Merchant’s environment in a PCI compliant manner. It is not intended to be a complete installation guide. Integrators may include e.g. Electronic Cash Register (ECR) vendors integrating Nexi payment terminal with their POS system using Nexi POS protocol [3], or Vending Machine vendors integrating Nexi payment terminal into the vending machine.

NOTE: Merchant/Reseller/Integrator responsibilities and actions are marked with MERCHANT ACTIONS in this document.

Version and review history is shown in the section Version history. This section provides an introduction, describes the review and update process, and lists abbreviations and references. Payment Card Core usage is described in the section Payment Application usage and the details are described in the section Payment Card Core module including centralized logging. Troubleshooting information is provided in the section Troubleshooting procedures. Appendix A lists and addresses all the PCI Secure Software requirements related to this document.

Document review and update process

Nexi must review this document on an annual basis and update it as needed to document all major and minor changes to the Payment Card Core module.

The Secure Software scope is the Payment Card Core module only as Payment Card Core takes care of all sensitive data handling. Changes outside the Payment Card Core module need not to described or managed with the Implementation Guide review process. If this scope is changed by QSA, this document must be updated to reflect the new scope. Also, this document is updated and reviewed in a timely manner whenever the PCI Secure Software Standard (PCI SSS) is updated.

Review process includes Nexi internal review by an individual other than the editor of the change and knowledgeable of the Payment Card Core module internals. Document must be reviewed by a PCI Secure Software QSA, during the change control process with the QSA.

Distribution

This document is initially distributed to all customers and resellers latest with the first product delivery via customer service portal or other means. Each of will be notified when this document is updated along with the updated document. This update notification happens through the customer service portal. This portal lists the IG version number and a link to this document. Whenever this document is updated, approved, and applicable to the payment terminals on the field with customers, the IG is uploaded to the service portal and the link to the document is updated. Note also that the latest version of this guide can be obtained from technical support. The master document is stored into the Nexi internal version management system.

Abbreviations

ECR
QSA| Qualified Security Assessor
TLS| Transport Layer Security

PAYMENT APPLICATION USAGE

Payment Application usage Strong access control measures must be used in all PCI scoped system components by using unique user Ids, strong passwords, and PCI DSS compliant secure access authentication, for more details see [1]. However, note that when using Nexi terminal there is no need to handle or store cardholder data outside the terminal. In the Nexi Payment terrminal there are no user configurable Payment Card Core settings. Also, there are no user accounts (or administrative accounts) to be configured or any user passwords/- credentials to be updated or reset. Nexi payment terminal supports ECR integration with JSONPOS protocol. Nexi payment terminal can only be used with Nexi payment gateway. Nexi payment terminal requires Internet connection for communicating with the payment gateway. Ethernet wiring can be used to provide the network connection and connection with the ECR. Cellular or Wireless LAN may be used for communication if wireless communication is preferred.

INSTALLATION ENVIRONMENT

Payment Terminal handling

The payment terminal must be installed according to Nexi installation instructions and along the Merchant actions requirements described in this document. Payment terminals must be periodically inspected for evidence of tampering and substitution (e.g., additions of card skimming devices), and merchant personnel must be trained for payment terminal inspections (see [4]). Also, an up-to-date list of payment terminals must be kept either by Merchant or provided by Nexi.

• MERCHANT ACTIONS***: Train personnel working with payment terminals on how to inspect payment terminals for evidence of tampering and substitution. The training must include at least the following:
• Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot payment terminals.
• Do not install, replace, or return payment terminals without verification.
• Be aware of suspicious behavior around payment terminals (for example, attempts by unknown persons to unplug or open devices).
• Report suspicious behavior and indications of payment terminal tampering or substitution to appropriate personnel (for example, to a manager or security officer).
• MERCHANT ACTIONS***: Inspect payment terminals for evidence of tampering and substitution periodically. The period can be based on Merchant’s own risk analysis.
• MERCHANT ACTIONS***: Merchant must have payment terminal registry for all its payment terminals. For Nexi payment terminals, this registry is provided by Nexi. Ensure Nexi has most up-to-date information about each payment terminal. The registry must include model of the device, location, and device serial number. Merchant must inform Nexi, whenever a payment terminal is relocated, decommissioned, removed, or added into production.

Network firewall configurations

There are no specific requirements on network segmentation when using Nexi payments terminal and when the Nexi Finland is the only medium used to read payment cards. See above.

• MERCHANT ACTIONS: Nexi payment terminal uses external service provided only by Nexi. For the Nexi payment terminal the TCP port 443 for host pt.api.npay.eu to the Internet (outbound) must be opened. Also DNS resolution for the host must be allowed. In addition, port 10001 must be allowed to connect to the payment terminal (inbound) from the ECR (when integrated with ECR). See the protocols below.

Wireless LAN

If the merchant uses wireless LAN to route the Nexi payment terminal connection to the Internet or the payment terminal uses wireless technology, it must be configured securely. This means that PCI DSS requirements must be followed when implementing the wireless networks:

**MERCHANT ACTIONS:**

• Encryption keys must be changed from default at installation and must be changed anytime anyone with knowledge of the keys leaves the company or changes positions.
• Default SNMP community strings on wireless devices must be changed.
• Default passwords on access points must be changed.
• Firmware on wireless devices must be updated to support strong encryption for authentication and transmission over wireless networks. WEP algorithm is not allowed.
• Any security-related wireless vendor defaults must be changed, if applicable.
• The default Service Set ID (SSID) must be changed.
• Firewall(s) must be installed between any wireless networks and systems that store cardholder data. This firewall(s) must be configured to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment.

PAYMENT CARD CORE MODULE

Initial Payment Card Core distribution

The Payment Card Core is initially distributed along with the payment terminal or if absent, the payment terminal will install the Payment Card Core from the update server during the first boot with network connection. In any case, during the boot up sequence the Payment Card Core will be updated from the update server if needed.

Versioning scheme for Payment Card Core module

The versioning scheme for the Payment Card Core module is .. where the components are as follows:

x – version major, incremented for major changes like new terminal platform or major new feature
y – version minor, incremented on each change, reset to 0 when version major is incremented
z – hotfix, incremented on changes are backported from mainline version on top of the release line version, 0 used for the mainline version

Hardware dependencies

Nexi payment terminal uses hardware provided by the Castles Technology Co. Ltd payment terminal manufacturer. Dependent hardware are:

attended terminal
Castles Technology Co. Ltd VEGA3000| PTS Approval 4-80055 PTS-approved attended terminal

Dependent Castles operating system version is Castles Linux OS xx20. Payment Card Core can be used in different configurations:

• Integrated with an attended ECR
• Standalone

Payment Card Core software dependencies

Nexi provides the payment application including Payment Card Core, which runs inside the terminal operating system on the terminals listed above. For developing the Payment Card Core, SDK from terminal manufacturers is required. Nexi payment terminal supports connection to the network with Ethernet wiring or wireless using WLAN or cellular.

In addition, Payment Card Core requires some external software components during the software development process and running the Payment Card Core. These components are managed and updated by Nexi. These software components are linked into the software package and thus delivered as part of the payment terminal SW. Nexi takes care that these software components are up to date e.g., through vulnerability management and software update processes and procedures.

Protocols used by the Nexi payment terminal SW

Payment Frontend

Nexi payment terminal SW uses TLS 1.2 or newer with strong cryptography to communicate with the payment frontend on TCP port 443. The payment terminal authenticates the frontend using a Nexi CA root, while the client is authenticated using OAuth2 tokens. All requests to the frontend are OAuth2-authenticated HTTPS requests which the frontend forwards based on the request URI. A Websocket connection, initialized using a HTTPS Upgrade header, is used to carry a JSON-RPC connection to the Payment Gateway, providing transaction data transfer, authorizations, and other payment related messaging.

The payment terminal communicates only with the Nexi Digital Finland payment gateway.

POS Protocol for ECR integrations

The terminal uses Nexi JSONPOS protocol for communicating with the ECR and listens on TCP port 10001. The ECR initiates communication with the terminal. The JSONPOS protocol never transmits sensitive cardholder data to the ECR, PANs are masked (only the first six and maximum four last digits are shown) for transaction receipt purposes.

Software Updates

Payment application including Card Core is packed into a platform specific SW package that will be automatically updated to the payment terminals. Chapters below describe the details per platform.

Software Updates (Castles terminals)

The payment terminal checks for updates and downloads update package(s) using JSON-RPC requests sent to the Payment Frontend which forwards them to the update server. The payment terminal reports its current software versions in an update check request, and the update server response indicates either that software is up-to-date or that specified updates need to be installed. The server is responsible for preventing unintended downgrades.

The update packages are SHA256 hash validated before installation, and the update package format itself contains a digital signature which Castles system software checks before installation. Software update packages are signed by Nexi under dualcontrol as specified by Castles.

Key Management

Payment terminal key management happens automatically. No user or merchant can have access to the payment terminal keys. There are no settings menu or other inputs to the terminal that would affect the key management. Software updates take care of updating keys, if ever needed. Also, the software updates happen automatically. No user or merchant actions are required.

The payment terminal uses OAuth2 to manage a refresh token and a bearer token. The first OAuth2 refresh token is obtained using an initial token fixed in the software build. When the first refresh token has been successfully taken into use, the initial token is no longer accepted; refresh tokens are then chained so that a new refresh token is fetched using the current refresh token. An administrator may manually allow a token refresh if a terminal loses its token state. The terminal requests for a token update on every boot (every 24h) which may update the refresh token and the bearer token. The bearer token is used for other HTTPS requests such as update checks, payment gateway connection, etc.

The PCI SSF scoped Payment Card Core modules uses RSA 2048-bit encryption to encrypt sensitive cardholder data. Only the payment gateway can decrypt the RSA encrypted data. The RSA public key is installed into the terminal from signature verified packet and updated automatically by Nexi.

Centralized logging

Nexi payment terminals implement centralized logging into the payment gateway. The centralized logging is based on a reliable event delivery protocol implemented by Nexi.

Logging is enabled automatically. Interfering with the logging functionality or disabling logs is not allowed and will result in noncompliance with PCI DSS. Note that it is not possible to disable logging from the payment terminal itself.

Merchants can obtain centralized logging events for their payment terminals on request from Nexi.

• MERCHANT ACTIONS: If merchant needs logging data for some of its terminals containing Payment Card Core, contact Nexi.

TROUBLESHOOTING PROCEDURES

Nexi will never request Sensitive Authentication Data (SAD) from customers, including e.g., full PAN, in any situation, including possible troubleshooting cases. In some cases, masked PAN (first six and last four digits) as printed on transaction receipt may be requested.

REFERENCES

PCI Security Standards Council, 2018
Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 3.2.1

PCI Security Standards Council, 2023
Software Security Framework, Secure Software Requirements and Assessment Procedures, Version 1.2.1s

Nexi JSONPOS API
https://poplapay.com/dev/jsonpos-api/

PCI Security Standards Council, 2014
Information Supplement, Skimming Prevention: Best Practices for Merchants, Version 2.

APPENDIX A:

PCI SSS v1.2 Requirements for the Implementation Guidance

All software security controls, features, and functions are enabled upon software installation, initialization, or first use.

• Software doesn’t have any user configurable security options or parameters (2.2.c) |

Default authentication credentials or keys for built-in accounts are not used after installation, initialization, or first use

• Software doesn’t require any user actions to set authentication credentials or keys

The privileges and resources requested by the software from its execution environment are limited to those necessary for the operation of the software. Software doesn’t have any user-configurable security options or parameters

• Software doesn’t have any user configurable security options or parameters

The software only retains the sensitive data absolutely necessary for the software to provide its intended functionality.

• There are no user configurable retention periods in the software (3.1.d)

Transient sensitive data is retained only for the duration necessary to fulfill a legitimate business purpose.

• There are no user configurable options for retention of transient sensitive data in the software (3.2.d)

The software protects the confidentiality and integrity of sensitive data (both transient and persistent) during retention.

• There are no user protections methods requiring user input or interaction (3.3.e)

The software does not disclose sensitive data through unintended channels

• There are no user protections methods requiring user input or interaction (3.6.c)

Software security controls are implemented to mitigate software attacks. |

• There are no user input or interaction that could be used to disable, remove, or bypass any mitigations for software attacks (4.2.c)

Access to critical assets is authenticated.

• The software doesn’t recommend, suggest, rely on, or otherwise supports the use of external mechanisms to provide secure non-console access to the system on which the software is executed or directly to the software itself (5.1.c)

Sensitive data is secured during transmission.

• The software doesn’t rely on third-party or execution-environment features are upon for the security of the transmitted data (6.2.c)

Use of cryptography meets all applicable cryptography requirements within this standard.

• The are no user configurable options for the cryptographic methods used by the software (6.3.b)

The software supports industry standard key management processes and procedures. Industrystandard key management processes and procedures are those recognized by industry standards bodies, such as NIST, ANSI, and ISO.

• There is no user installable key material of certificates used by the software (7.2.f)

The software vendor provides stakeholders with clear and thorough guidance on the secure implementation, configuration, and operation of its payment software.

• The distribution of the document is described in chapter Distribution
• Software installation is fully controlled by Nexi and the end user can’t do any SW installations to the terminal
• Terminals don’t have user accounts and user can’t control any security features of the terminal
• Software update mechanism is described in Software Updates
• Key management described in Key Management

The software vendor provides guidance to stakeholders regarding secure deletion of cardholder data after expiration of defined retention period(s).

• No user actions are needed for secure deletion of cardholder data

The software provides features to restrict or otherwise mask all displays of PAN to the minimum number of digits required.

• No user input or interaction is required to configure PAN masking features and options (A.2.2.c)

PAN is rendered unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs)

• No user input or interaction is required to configure methods to render PAN unreadable when stored (A.2.3.b)

PAN is rendered unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs)

• Software for the terminal can only be signed by the terminal vendor or the software vendor (B.2.8.a)

The integrity of software prompt files is protected in accordance with Control Objective B.2.8.

• The prompt files are built in into the signed software package (B.2.9.b and B.2.9.c)

The software vendor provides implementation guidance on how to implement and operate the software securely for the payment terminals on which it is to be deployed

• This document provides the relevant information

Implementation guidance includes detailed instructions for how to configure all available security options and parameters of the software. |

• Software doesn’t have any user configurable security options or parameters

Implementation guidance includes detailed instructions for how to securely configure the software to use the security features and functions of the payment terminal where applicable |

• Software doesn’t have any user configurable security options or parameters

Implementation guidance includes detailed instructions for how to configure the software to securely integrate or use any shared resources provided by the payment terminal. |

• Payment Card Core is only integrated into the Nexi provided payment terminals by Nexi

Implementation guidance includes detailed instructions on how to cryptographically sign the software files in a manner that facilitates the cryptographic authentication of all such files by the payment terminal. |

• Software module can’t be signed by the customers, only by Nexi

Implementation guidance includes instructions for stakeholders to cryptographically sign all prompt files. |

• Prompt files are only signed by Nexi

Implementation guidance adheres to payment terminal vendor guidance on the secure configuration of the payment terminal. |

• Software doesn’t have any user configurable security options or parameters

Distribution List

Product
Nets.eu| Merchants who use the Npay Software through Nets & Nexi payment terminals are to access the implementation guide through the support pages of Nets.eu

References

• Nets A/S - International website
• JSONPOS API – Poplapay Developers

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>