Document title: SP900 Software Implementation Guide

Department: Product & Technology

Author: Magnus Lasses
Classification: For public use
Version: 2.05
Previous Version: 2.04
Revision date: 2017-05-21

SP900 SOFTWARE IMPLEMENTATION GUIDE

Version: 2.05

Bambora
P.O. Box 17026, SE-104 62 Stockholm
Visit: Regeringsgatan 65
Tel: +46 10 10 66 000
support@bambora.com
Bambora AB, reg. nr. 556233-9423. P.O. Box 17026, SE-104 62 Stockholm
bambora.com
1 Revision History
Rev Pages Description Date and sign
1.0 All New document 2012-10-30 - JH
1.1 17 Clarified Wireless section 2013-01-30 - JH
1.2 16 Update of PCI DSS reference 2013-02-12 - JH
20 Update of PA-DSS reference
1.3 6,8,10,11,14,18 Added iSMP and more ECR devices 2013-03-04 – ML
1.3.1 2 Added PA-DSS impact table 2014-05-15 – PT
1.3.2 2 Added new version (no-impact) 2014-10-07 - ML
1.4 All Revised the whole document for PA DSS 3.1 2015-08-24 - ML
1.5 12 Added info in Application Versioning 2015-10-01 - HS
1.6 19 Updated referenced PA-DSS version 2015-10-05 -HS
21 Clarified the wireless preferences
1.61 6, 15, 17, 19 Clarified some points regarding communication 2016-01-06 - ML
2.0 All Revised for name change to Bambora Device AB 2016-01-21- ML
2.01 2, 6, 7, 12, 13 Added Sofie 2016-02-08 - ML
2.02 2,5, 11,12,15, 20 Added new version, and removed IWL280 & 2016-08-24 - ML
ISMP
2.03 7,9, 14, 18 Clarified the payment flows, clarified software 2016-10-20 - ML
updates, HowTo turn off system restore for
windows 10
2.04 2 Since no impact changed version to 201 2017-02-20 - ML

Software version PA-DSS impact Description

SP900_103 High Added support for ISMP and ISMP Companion
SP900_104 No-Impact Maintenance version with bug fixes including Host2T
1.9 & 2.x and Duo
SP900_200 High Added support for contactless and New PA-DSS
approval (3.1)
SP900_201v1 Low-impact Added support for Sofie and CashAdvance
SP900-201v2 No-Impact Added support for DCC, MultiUser, MobilePay and
Invoice

2(23)
2 Abbreviations
3DES = Triple Data Encryption Standard. Aka TDES
DUKPT = Derived Unique Key Per Transaction
ECR = Electronic Cash Register
IPSEC = Internet Protocol Security
NAT = Network Address Translation
MAC = Message Authentication Code
PAN = Primary Account Number
PA-DSS = Payment Application Data Security Standard
PCI = Payment Card Industry
PCI – DSS = PCI Data Security Standard
PIN = Personal Identification number
PAT = Port Address Translation
RADIUS = Remote Authentication and Dial-In User Service
SSH = Secure Shell
VPN = Virtual Private Network
SSL = Secure Sockets Layer
TACACS = Terminal Access Controller Access Control System
TCP/IP = Transmission Control Protocol / Internet Protocol
TLS = Transport Layer Security
WEP = Wired Equivalent Privacy
WPA/WPA2 = WiFi Protected Access
BT = Bluetooth
E2EE = End To End Encryption
SAD = Sensitive Authentication Data
CHD = Card Holder Data

3(23)
3 Index
1 Revision History ........................................................................................................................ 2
2 Abbreviations ............................................................................................................................ 3
3 Index ........................................................................................................................................ 4
4 Introduction ............................................................................................................................... 5
5 General Description Of The Products ......................................................................................... 6
5.1 The Payment Flow – ICT2XX/IWL2XX (Host2T, Host2T2, Sharp, Sofie, Stand-alone) .............. 7
5.2 The Payment Flow – ICT2XX/IWL2XX/IPP3XX (Host2T2) ...................................................... 9
6 Requirements ..........................................................................................................................11
6.1 Stand-Alone........................................................................................................................11
6.1.1 Hardware Requirement ...................................................................................................11
6.1.2 Software Requirement ....................................................................................................11
6.2 Integrated ...........................................................................................................................11
6.2.1 Hardware Requirement ...................................................................................................11
6.2.2 Software Requirement ....................................................................................................12
6.2.3 Network & Services Requirement ....................................................................................12
7 Implementation ........................................................................................................................13
7.1 Application Versioning Methodology .....................................................................................13
7.2 Secure delivery of remote payment application updates. ........................................................14
8 Support ...................................................................................................................................15
9 Security Usage ........................................................................................................................16
9.1 Delete Sensitive Authentication Data Stored By Previous Payment Application Versions .........16
9.2 Mask PAN ..........................................................................................................................16
9.3 Delete Any Sensitive Authentication Data (Pre-Authorization) Gathered As A Result Of
Troubleshooting The Payment Application .....................................................................................16
9.4 Purge Cardholder Data After Customer-defined Retention Period...........................................17
9.5 Delete Cryptographic Key Material Or Cryptograms Stored By Previous Payment Application
Versions ......................................................................................................................................19
9.6 Use Unique User Ids And Secure Authentication For Administrative Access And Access To
Cardholder Data ...........................................................................................................................19
9.7 Use Unique User Ids And Secure Authentication For Access To PCs, Servers, And Databases
With Payment Applications ............................................................................................................19
9.8 Implement Automated Audit Trails ........................................................................................19
9.9 Securely Implement Wireless Technology .............................................................................20
9.10 Cardholder Data Must Never Be Stored On A Server Connected To The Internet ....................21
9.11 Facilitate Secure Remote Access To Payment Application .....................................................21
9.12 Encrypt Sensitive Traffic Over Public Networks .....................................................................22
9.13 Encrypt Non-console Administrative Access .........................................................................22
9.14 Key Management ................................................................................................................23

4(23)
4 Introduction
Bambora has developed a payment application called SP900 that resides within the terminals from the
manufacturer Ingenico. This is an implementation guide for the Bambora Ingenico terminals.

It is a complementary document to any additional protocol documents that are used for integrating an
external ECR application connected to the terminal. This document must be read before the integration
is started.

This Implementation Guide should be disseminated to all relevant application users including merchants
and resellers/integrators. The guide should instruct merchants, resellers and integrators how to install
the Bambora products in a PA-DSS 3.2 compliant manner. It is not intended to be a complete
installation guide.

It should be updated at least annually and after changes in the software. The annual review and
update should include new software changes as well as changes in the PA-DSS standard.

Updates to the Implementation Guide can be obtained by contacting the technical support. (See chapter
8 for contact information) or by downloading it from the partner portal.

Note! If you do not follow, the steps outlined in this implementation Guide, your installation will not be
PA-DSS 3.2 compliant.

5(23)
5 General Description Of The Products
The payment application will run on terminal hardware from the manufacturer Ingenico based on their
Telium 2 platform. This platform makes it possible to run the same application on 3 different model
families, the ICT2XX, IWL2XX, and the IPP3XX.

ICT2XX and IWL2XX are standalone terminals with the functionality to connect to an ECR through
Bambora’s own Host2T 1.9 and Host2T version 2.x protocol, hereafter called Host2T2. Sharps EFT
protocol and Sofie protocol are also available for connection to a ROM cash registers.

The IPP3XX series on the other hand are “Integrated Terminal” only and has to be connected to an ECR
through Host2T2.

The communication between terminal and cash register is either Ethernet, Serial (RS232 or Bluetooth)
or USB for Host2T, and Host2T2. The Sharp & Sofie protocol is only supported with the Serial
connection through RS232.

This guide will cover the models ICT250, IWL250, IPP350.

The terminal communicates with Bambora Base24 server, which is located in the PCI DSS approved
Bambora card environment, the PTS approved terminal hardware communicates through Ethernet,
GPRS, 3G, WiFi or Bluetooth.

The Bluetooth version connects to a Bluetooth access point that has connection to Internet or through a
3rd party device (i.e. PDA). If merchants are using WiFi connections in the same environment as the
terminal it is most important that WPA2 (TKIP or AES) encryption is used to sustain a PA-DSS 3.2
compliant merchant environment.

The terminals have a magnetic strip reader and a smart card reader. All of the models are equipped
with a contactless reader, which is enabled (if using version 200v1 or later of the payment application
and have enabled the feature in the partner portal).

6(23)
 5.1 The Payment Flow – ICT2XX/IWL2XX (Host2T, Host2T2,
Sharp, Sofie, Stand-alone)
PC/ROM cash register
CHD flow for authorization

1.

Host2T/Host2T2/Sharp/Sofie
Eth/RS232/USB

4.
3.
Merchant firewall Bambora firewall

2.

WAN/Internet
Ingenico ICT2XX/IWL2XX terminal
Ethernet/3G/GPRS/Bluetooth Bambora payment gateway Card processor
Traffic encrypted using TDES with DUKPT scheme

Diagram 2-1 the payment flow

1. The cashier chooses card payment in the terminal menu or by an ECR connected cash register.
The cash register application contacts the terminal through selected protocol, for the type of
cash register installed. It is also possible to insert the card into the card reader to initiate a
transaction, when used as a stand-alone terminal.

2. The terminal will start up the card information gathering process. The terminal will display
directives for the card holder what to do.
 The cardholder will either swipe, insert or tap the card in/on the terminals integrated
reader to collect the card information. Alternative the card holder will enter the PAN,
expire date and CVV2 (if required by the issuer) in the terminal PED.

 The Bambora payment application in the terminal, will TDES encrypt (with DUKPT
scheme) the cardholder data (CHD) and sensitive authentication data (SAD) that is
gathered in the previous step. When the terminal has all the information it needs for
authorization, it will contact Bambora Payment Gateway.

3. The Bambora payment gateway authorizes the payment request from the terminal against a
card processor. The result from the authorization will be processed and returned to the
terminal. The result sent from the processor to the terminal, contains no CHD or SAD.

The payment application in the terminal hold the CHD and SAD in VRAM until a result is
received from the processor or until the terminal times out, thereafter the CHD and SAD is
purged. Before the CHD is purged, the PAN is saved truncated for receipt information, see
below.

7(23)
4. The terminal will show the Result on the display or if a cash register is connected the terminal
will return the following information back to the cash register:

 Response code from the bank.

 Bambora unique authorization number.
 Bank unique authorization number.
 Truncated PAN, only the last 4 digits. (e.g. **** **** **** 1234)
 EMV application information.
 Loyalty card number, bonus card number (Never Visa, Visa Electron, MasterCard,
Maestro, American Express, Diners or JCB)

5. The terminal will print a receipt with truncated PAN together with other insensitive data.
Alternatively, if a cash register is used, it could print a receipt instead of the terminal.

8(23)
 5.2 The Payment Flow – ICT2XX/IWL2XX/IPP3XX (Host2T2)

Ingenico ICT2XX/IWL2XX/IPP3XX terminal

Traffic encrypted using TDES with DUKPT scheme CHD flow for authorization
2.

Host2T2
Eth/RS232/USB
3.
4.
5. 6. Merchant firewall Bambora firewall

1.

WAN/Internet
PC/ROM/Tablet
Bambora payment gateway Card processor
cash register

Diagram 2-2 the payment flow

1. The cashier chooses card payment in the ECR connected Cash register The Cash register
contacts the SP900 application through the protocol (HOST2T2), to initiate a transaction.

2. The terminal will start up the card information gathering process. The terminal will display
directives for the card holder what to do.

 The cardholder will either swipe, insert or tap the card in/on the terminals integrated
reader to collect the card information. Alternative the card holder will enter the PAN,
expire date and CVV2 (if required by the issuer) in the terminal PED.

 The Bambora payment application in the terminal, will TDES encrypt (with DUKPT
scheme) the cardholder data (CHD) and sensitive authentication data (SAD) that is
gathered in the previous step.

3. The Authorization is sent encrypted tunneled through the PC/ECR with Host2T2 protocol to the
Bambora Gateway.

4. The Bambora payment gateway authorizes the payment request from the terminal against a
card processor. The result from the authorization will be processed and returned to the
terminal. The result sent from the processor to the terminal, contains no CHD or SAD.

The payment application in the terminal hold the CHD and SAD in VRAM until a result is
received from the processor or until the terminal times out, thereafter the CHD and SAD is
purged. Before the CHD is purged, the PAN is saved truncated for receipt information, see
below.

9(23)
5. The terminal will show the Result on the display and the terminal will return the following
information back to the connected cash register:

 Response code from the bank.

 Bambora unique authorization number.
 Bank unique authorization number.
 Truncated PAN, only the last 4 digits. (e.g. **** **** **** 1234)
 EMV application information.
 Loyalty card number, bonus card number (Never Visa, Visa Electron, MasterCard,
Maestro, American Express, Diners or JCB)

6. The terminal will print a receipt with truncated PAN together with other insensitive data.
Alternatively, if a cash register is used, it could print a receipt instead of the terminal.

10(23)
6 Requirements
6.1 Stand-Alone
6.1.1 Hardware Requirement
- Ingenico ICT250 or IWL250.

Recommended cable to use

- n/a

6.1.2 Software Requirement

- Bambora application SP900-201v2

6.2 Integrated
6.2.1 Hardware Requirement
- Ingenico ICT250, IWL250, IPP350.
- PC, Tablet or ROM cash register

Recommended cable to use

- Ingenico USB B Male Angled to USB A Male cable to connect to PC/ECR for ICT2XX
- Ingenico RS232 Cable connect to PC/ECR for ICT2XX
- Ingenico Magic box Ethernet with 1 RS232 and Cover flap connect to PC/ECR for ICT2XX
- Ingenico Long spiral cable DB9 powered by POS or external PSU For Taxi Solution with IPP3XX
- Ingenico USB Type A Powered Curly cable, to connect to PC/ECR for IPP3XX

11(23)
6.2.2 Software Requirement
- Bambora application SP900-201v2

- Cash register with one of the following option.(ICT2XX and IWL2XX)

o PC Cash register application with Host2T support
o PC Cash register application with Host2T2 support
o ROM Cash register from Sharp
o ROM Cash register with Sofie protocol support
o PC Cash register application with Sofie protocol support
o PDA Cash register application with Host2T2 support
o Tablet Cash register application with Host2T2 support

- Cash register with the following option (IPP3XX).

o PC Cash register application with Host2T2 support
o Taximeter with Host2T2 support

6.2.3 Network & Services Requirement

The terminals rely on having an internet connection, these IP addresses and ports needs to be opened
in the firewall. However, the terminal should not be connected directly to the Internet – it must be
placed behind a firewall to prevent inbound connections from the Internet to the device. The terminals
does not rely on any other services.

Authorizations (Gateway):
91.224.37.30
62.109.41.50
62.109.60.50
Outbound TCP port: 975

Updates (TMS):
IP: 91.224.37.30
Outbound TCP port: 979

Terminal Settings (PPL):

IP: 91.224.37.30
Outbound TCP port: 979

12(23)
7 Implementation
The cash register vendor needs to implement a client application in order to establish the connection.

The document “HOST2T PROTOCOL SPECIFICATION EN201XXXXXXX.pdf” is the technical specification

for HOST2T. Host2T2 is described in “HOST2T 2.x PROTOCOL SPECIFICATION EN201XXXXXXX.pdf”.
They describe how to use and implement the Host2T and Host2T2 protocol. For protocols documents
released for Sharp EFT, please contact Sharp Electronics AB for the Sharp protocol. For Sofie protocol
Bambora only supports existing ECR implementations.

7.1 Application Versioning Methodology

The Bambora versioning methodology consists of a three-digit software version number, XYY, extended
with a variable indicating a wildcard, v*. The version number are always written in a cohesive row,
without separators.

X = first digit, can vary between 1-9

YY = second and third digit, can vary between 00-99
v* indicates version of the wildcard, where * can vary between 1-99.

• An increase of the first digit (X), e.g. from 100 to 200, is a high impact update to the
payment flow. These changes do have an impact on the security of the application
and/or the PA-DSS requirements.

• An increase of the second and third digit (YY), e.g. from 103 to 110, is a low impact
update or bug fix of the payment flow. This has impact on the application functionality
but does not affect the security of the application or the requirements of the PA-DSS.

• An increase of the wildcard version (v*), e.g. from 100v2 to 100v3, is a no impact or
administrative update or bug fix. This has no impact on the functionality of the
application or its dependencies; neither does it affect the security of the application or
the requirements of the PA-DSS.

The PA-DSS change impact level is always described in the Implementation Guide (page 2). The change
description in the Implementation Guide states if the change is considered a high-impact change, low-
impact change or no-impact change. It also includes a change impact analysis, if the change affect PA-
DSS requirements or the security of the application. The table in the Implementation Guide is updated
for every application release. All vendors/parties involved, must follow the provided and current
Implementation Guide to be aware of changes in the software currently used.

13(23)
7.2 Secure delivery of remote payment application updates.
The Bambora payment application is distributed to the terminal in a secure manner. The terminal
retrieves the software from Bambora TMS using a proprietary protocol called Datax 2 and the
connection is secured using TLS 1.2 encryption.

Before the new application is upgraded in the terminal, the application signature is verified to make sure
it is a software, which is allowed to run on the terminal. Only software that has been signed with the
proper Bambora key is allowed to exist and run in the terminal.

Information of a new update is sent out prior to the release to relevant parties so that testing of ECR
connections can be performed.

Automatic software updates are usually delivered to the terminal after a settlement has been done,
which terminals get the automatic update is handled by Bambora centrally and the merchant does not
need to do anything to get new updates.

If you want to update the terminal manually please follow these steps on the terminal:
1. Press menu button
2. Press 6. Administration
3. Press 2. Update software
4. Please allow time for the terminal to download the software
5. The new software has been downloaded and the terminal is ready for use again

If there are any questions please contact our support, the contact details can be found in chapter 8.

14(23)
8 Support
If there are any questions regarding the implementation of one of the Ingenico models or a copy of the
latest implementation guide, please contact technical support at support@bambora.com or +46(0)10–
10 66 000, between 9.00-20:00 (GMT+1) on non-holiday weekdays and 10:00-14:00 on Saturdays. The
Bambora Partners can also find the implementation guide on the Partner web portal.

15(23)
9 Security Usage
The ICT2XX, IWL2XX and IPP3XX models from Ingenico must be used according to the PCI PA-DSS
(Payment Card Industry Payment Application-Data Security Standard). By using these products means
that you have accepted and follow the PCI DSS and PCI PA-DSS. Please visit
https://www.pcisecuritystandards.org/ for the standards.

The following chapters describe how the terminals must be used in order to comply with PA-DSS and
PCI DSS version 3.2.

9.1 Delete Sensitive Authentication Data Stored By Previous

Payment Application Versions

Resellers and merchants applicability:

The terminal will remove the SAD after the transaction has been acknowledged by the gateway. SAD is
only ever held in the RAM and the stored elements are the encrypted PAN and expiry, if an offline
transaction has been performed, otherwise only the 4 last digits of the PAN is stored( masked PAN)

All versions of the SP900 application has never stored the SAD.

The terminals clear all of the transaction data from the memory when a register closing is done. Before
installing a new version to the Ingenico terminal, make a register closing to remove transaction data
from the terminal. The terminal will not update before this has been performed.

9.2 Mask PAN

Resellers and merchants applicability:

The terminals always masks PAN when it comes to the card brands Visa, Visa Electron, MasterCard,
Maestro, American Express, Diners and JCB. The PAN is masked on all digits except the four last e.g.
**** **** **** 1234 and this is done on the receipt, on the screen and sent in the communication
between the terminal and the ECR cash register.

The masked PAN can be found on receipts, transaction reports and in the review function of the
terminal.

Unmasked PAN on the major brands are never shown, communicated or printed and it is not possible to
configure the terminal to show full PAN.

9.3 Delete Any Sensitive Authentication Data (Pre-Authorization)

Gathered As A Result Of Troubleshooting The Payment
Application

Resellers and merchants applicability:

Sensitive authentication data is not stored by the terminal during transactions or when used for trouble
shooting. Bambora does not need SAD for trouble shooting, as a merchant, partner or support person
you shall never log, collect or try to provide SAD to Bambora.

16(23)
9.4 Purge Cardholder Data After Customer-defined Retention
Period

Resellers and merchants applicability:

The Bambora SP900 application do not store any card validation codes, PINS or PIN blocks after the
Authorization on any memory within the terminal and do not send this data to the ECR cash register.

Clear text card data from Visa, Visa Electron, MasterCard, Maestro, American Express, Diners and JCB
will never be available outside the SP900 application. Clear text PAN that will be found outside the
application will be restricted by a BIN list that is stored in the terminal (Loyalty and bonus card
purpose).

Encrypted PAN and encrypted expire date is returned to the cash register for offline transactions and is
printed on the merchants receipt. This data shall not be stored by the ECR application.

This gives the possibility to try to recreate the transaction if the terminal breaks down before the
transaction is delivered to the Bambora system. The receipts shall be rendered unreadable in a secure
manner after the daily closing has been performed and it is validated that the offline transactions has
been delivered to the Bambora system.

No guidance for deleting card data is needed for either the terminal or cash register. The terminal
deletes encrypted card data that is stored on the store and forward queue, when an online transaction
is sent to Bambora, if the Background activities feature is enabled or when the terminal performs a
register closing.

If cardholder data is obtained it shall be deleted in a secure manner when the data is no longer required
for legal, regulatory or business purposes.

17(23)
For terminals connected to windows PC cash registers, it is recommended that the system restore is
disabled for security purposes. The cash register shall never store encrypted cardholder data (received
from the terminal) and it shall not accept input or store cardholder data.
Follow the instruction below:

Steps to turn off System Restore (Windows XP/Vista):

1) Click Start, right-click My Computer, and then click Properties.
2) In the System Properties dialog box, click the System Restore tab.
3) Click to select the Turn off System Restore check box. Or, click to select the Turn off System
Restore on all drives check box.
4) Click OK.
5) When you receive the following message, click Yes to confirm that you want to turn off System
Restore:
“You have chosen to turn off System Restore. If you continue, all existing restore points will be
deleted, and you will not be able to track or undo changes to your computer.
Do you want to turn off System Restore?”

After a few moments, the System Properties dialog box closes.

Steps to turn off System Restore (Windows 7):

1) Click Start, right-click Computer, and then click Properties.
2) Click on the “advance system settings” link under Control Panel Home.
3) In the System Properties dialog box, click the System Protection tab.
4) Make sure that all available drives has Protection Off. If Protection is On, highlight that drive
and then click on Configure…
5) Chose Turn off system protection.
6) Click OK.
7) When you receive the following message, click Yes to confirm that you want to turn off System
Restore:
“Are you sure you want to turn off system protection on this drive?
Existing restore points on the disk will be deleted and new restore points will not be created. You
will not be able to use System Restore to undo unwanted system changes on all drive.”

After a few moments, the System Protection dialog box closes

8) If necessary go back to 4 and disable system restore on other drives as well.

Steps to turn off System Restore (Windows 8 & 8.1)

1) Open System by clicking the Start button, right-clicking Computer, and then clicking Properties.
2) In the left pane, click System protection. Administrator permission required if you are prompted
for an administrator password or confirmation, type the password or provide confirmation.
3) Under Protection Settings, click the disk, and then click Configure.
4) Click Turn off system protection, click OK, and then click OK again.

Steps to turn off System Restore (Windows 10)

1) Click Windows logo in down left corner, and then write restore
2) Click “Create a restore point”.
3) Administrator permission required if you are prompted for an administrator password or
confirmation, type the password or provide confirmation.
4) Under System Protection Settings, click the disk, and then click Configure.
5) Click Turn off system protection, click OK, and then click OK again.

18(23)
9.5 Delete Cryptographic Key Material Or Cryptograms Stored By
Previous Payment Application Versions
Resellers and merchants applicability:
The Bambora SP900 application handles all the encryption of card holder data in the secure processor,
not reachable from outside the terminal. The data traffic is encrypted with 128-bit TDES using a DUKPT
key. The PIN block is also encrypted with a DUKPT key.

Cryptographic material is removed when a new application version is placed in the terminal. Historic
data should be removed according to PA-DSS 3.2; therefore, no historic data will need to be re-
encrypted. In all versions for the SP900 application the card holder data is encrypted with a unique key
per transaction.

9.6 Use Unique User Ids And Secure Authentication For

Administrative Access And Access To Cardholder Data

Resellers and merchants applicability:

There are no user accounts on the Ingenico terminals. Therefore there is no access any cardholder
data. This requirement is not applicable to any merchant or reseller using the terminal.

9.7 Use Unique User Ids And Secure Authentication For Access To
PCs, Servers, And Databases With Payment Applications

Resellers and merchants applicability:

The user has not the possibility to logon on to any cardholder data environment using Bambora’s
Ingenico terminals. The cash register vendor must provide unique user id and password to each cashier
when operating the ECR cash register

9.8 Implement Automated Audit Trails

Resellers and merchants applicability:
The payment application for the Ingenico terminals has logging activated as default. There is no
available setting to turn the logging off. If logging is somehow prevented or disabled, the merchant will
be non-compliant with PCI DSS.

The payment application utilizes centralized logging and sends the log files to a central server at
Bambora. The merchant may collect the logs from the centralized storage and processing according to
PA DSS and PCI DSS requirements, contact Bambora to receive instructions on how to collect the log
files, see section 8 for contact details.

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or
minimizing the impact of a data compromise. The presence of logs in all environments allows thorough
tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise
is very difficult without system activity logs. The ECR cash register shall implement extensive logging,
which can be used as assistance if a breach has been detected or problems are experienced.

19(23)
9.9 Securely Implement Wireless Technology

Resellers and merchants applicability:

A typical installation of a Bambora terminal is that the PTS approved terminal handles all the
communication with the Bambora Payment Gateway through following methods:

 GPRS/3G: The terminal communicates with payment gateway via the GPRS/3G network
 Bluetooth: The terminal communicates with payment gateway via a BT access point and
merchant network connection.
 Ethernet: The terminal communicates with payment gateway via merchant’s LAN/Ethernet.
 Serial(RS232, Bluetooth)/USB: The terminal communicates with payment gateway via a
connected PC/Tablet/iPhone/iPod/Taximeter/PDA and merchants WLAN/LAN

The SP900 application does not send any clear text cardholder data or have any remote access to
cardholder data over any media and the application does not handle the communication, this is done by
the PCI PTS approved terminal hardware.

If the merchant uses a wireless network make sure the wireless connections must be implemented
according to PCI DSS 3.2 Requirement 1.2.3, 2.1.1, and 4.1.1 below and logging must be switched on in
the firewalls.

According to the PCI DSS 3.2 Requirement 1.2.3:

Install perimeter firewalls between all wireless networks and the cardholder data environment, and
configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized
traffic between the wireless environment and the cardholder data environment.

According to the PCI DSS 3.2 requirement 2.1.1:

For wireless environments , including GPRS/3G and Bluetooth, connected to the cardholder data
environment or transmitting cardholder data, change ALL wireless vendor defaults at installation,
including but not limited to default wireless encryption keys, passwords, and SNMP community strings.

 Encryption keys were changed from default at installation

 Encryption keys are changed anytime anyone with knowledge of the keys leaves the company
or changes positions.
 Default SNMP community strings are required to be changed upon installation.
 Default passwords/phrases on access points are required to be changed upon installation.
 Wireless devices is updated to support strong encryption(at least WPA2) for:
o Authentication over wireless networks
o Transmission over wireless networks.
 Other security-related wireless vendor defaults apply, if appropriate.

According to PCI DSS 3.2 Requirement 4.1.1:

Ensure wireless networks transmitting cardholder data or connected to the cardholder data
environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for
authentication and transmission.
- For new wireless implementations, it is prohibited to implement WEP after March 31, 2009.
- For current wireless implementations, it is prohibited to use WEP after June 30, 2010.

If the merchant does not follow these requirements, the terminal is not PCI DSS compliant.

20(23)
9.10 Cardholder Data Must Never Be Stored On A Server Connected
To The Internet

Resellers and merchants applicability:

The Bambora SP900 application does not store any cardholder data after an authorization. All
authorizations are encrypted with 3DES DUKPT. Only encrypted PAN and expire date is stored
(encrypted with 3DES DUKPT), on the terminals secure flash memory, for offline transactions until they
are sent to the Bambora payment gateway. Once the terminal has gotten an acknowledgement from
the gateway on the sent authorization message, it will erase the data.

The terminal must not be connected directly to the Internet – it must be placed behind a firewall which
prevents inbound connections from the Internet to the device. Accessing the cardholder data in the
terminal from the internet is not possible. If the terminal is opened by external physical attack then the
self-destruction mechanism will be activated and the terminal will erase all keys. The terminal will not be
able to operate without any keys, the terminal must be sent to Bambora, and Ingenico to be repaired
and to be formatted so new keys could be injected.

The reseller or merchant shall at all times make sure that security patches for the used operating
system on the ECR are applied. If not the solution is not PA DSS 3.2 approved.

If the message “Alert Irruption” is shown on the terminal screen the terminals has been compromised
and must not be used, please contact Bambora support immediately and report this, the contact details
can be found in chapter 8.

9.11 Facilitate Secure Remote Access To Payment Application

Resellers and merchants applicability:

The Ingenico terminal does not support remote access to the payment application. This requirement is
not applicable to integrators using the terminals, due to that no Card holder data is released in clear
text outside the SP900 Payment Application.

The PCI PA DSS 3.2 requirements need to be met by the ECR cash register application:

Note: Examples of remote access security features include:

- Change default settings in the remote access software (for example, change default passwords
and use unique passwords for each customer and use 2 factor authentication).
- Allow connections only from specific (known) IP/MAC addresses.
- Use strong authentication and complex passwords for logins
- Using strong cryptography, render all authentication credentials (such as passwords/phrases)
unreadable during transmission and storage on all system components.
- Enable account lockout after a maximum 6 failed login attempts (See PA DSS Requirement
3.1.9).
- Configure the system so a remote user must establish a Virtual Private Network (“VPN”)
connection via a firewall before access is allowed.
- Enable the logging function.
- Restrict access to customer passwords to authorized reseller/integrator personnel.

Extracts from PCI DSS 3.2 requirements:

4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard
sensitive cardholder data during transmission over open, public networks, including the following:

 Only trusted keys and certificates are accepted.

21(23)
  The protocol in use only supports secure versions or configurations.
 The encryption strength is appropriate for the encryption methodology in use.

Examples of open, public networks include but are not limited to:
 The Internet
 Wireless technologies, including 802.11 and Bluetooth
 Cellular technologies, for example, Global System for Mobile communications (GSM), Code
division multiple access (CDMA)
 General Packet Radio Service (GPRS)
 Satellite communications

8: Identify and authenticate access to system components Assigning a unique identification (ID) to each
person with access ensures that each individual is uniquely accountable for their actions. When such
accountability is in place, actions taken on critical data and systems are performed by, and can be
traced to, known and authorized users and processes.

The effectiveness of a password is largely determined by the design and implementation of the
authentication system—particularly, how frequently password attempts can be made by an attacker,
and the security methods to protect user passwords at the point of entry, during transmission, and
while in storage.

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with
administrative capabilities and all accounts used to view or access cardholder data or to access systems
with cardholder data.

This includes accounts used by vendors and other third parties (for example, for support or
maintenance). However, Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 are
not intended to apply to user accounts within a point-ofsale payment application that only have access
to one card number at a time in order to facilitate a single transaction (such as cashier accounts).

9.12 Encrypt Sensitive Traffic Over Public Networks

Resellers and merchants applicability:

The Bambora SP900 application handles all the encryption of card holder data. The data traffic is
encrypted with TDES using a DUKPT key (128-bit). The PIN block is encrypted also using DUKPT. The
terminal communicates with a Base24 server at the Bambora PCI DSS compliant environment through
TCP/IP.

The Base24 server is the only unit that can decrypt the data from the terminal and vice versa. This
solution serves as a VPN tunnel (E2EE) between the terminal and Base24 server and therefore is the
ECR and the merchant out of scope.

9.13 Encrypt Non-console Administrative Access

Resellers and merchants applicability:

The Bambora Ingenico terminal settings and configuration cannot be accessed through any network.

The PCI PA DSS requirements need to be met by the ECR cash register application:

Extracts from PCI DSS 3.2 requirements:

2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as
SSH, VPN, or TLS for web-based management and other non-console administrative access.

22(23)
9.14 Key Management

Resellers and merchants applicability:

The Bambora SP900 application with Ingenico firmware and Bambora handles all the key management
on behalf of the merchant. PCI PA-DSS requirement 2.5 and 2.6 is not applicable to resellers using the
terminals from Ingenico with Bambora Payment Application SP900

Bambora and its partner Evry does all the handling and generation of the keys in a secure manner and
follows the standards set by the industry by implementing these rules and processes:

 Document every key and custodian.

 Restrict access to keys to the fewest number of custodians necessary.
 Generation of strong cryptographic keys.
 Store keys securely in the fewest possible locations and forms.
 Secure cryptographic key distribution.
 Secure cryptographic key storage.
 Cryptographic key changes for keys that have reached the end of their crypto period.
 Prevention of unauthorized substitution of cryptographic keys.
 Destroy old/unused keys in a safe manner.

The terminals are to be considered valuables and should be in a locked location when not used. When
the terminals has reached sun set date and shall not be used any more the terminal shall be destroyed
in a secure manner. If the merchant or reseller cannot provide this, the terminal can be sent to
Bambora for destruction. Please contact our support (contact details can be found in chapter 8).

23(23)