22
Version: 1.00.17 ACR900 PCI PTS Security Policy
Version: 1.00.17
ACR900
PCI PTS Security Policy
Page 2 of 22
Version History
Date By Changes Version
2014-12-21 Bruce Wang ● Initial Draft 0.00.01
2015-03-02 Dulce Tupino
● Updated the contents
● Rename the title
● Proofread
● Provide suggestions and comments
● Re-arranged the format
0.00.03
2015-03-03 Bruce Wang • Modify according to review result 0.00.04
2015-04-06 Cindy Delgado
• Proofread the document
• Re-arranged the format
• Deleted another PIN in Table 1
0.00.05
2015-05-04 Jack Tse • Added product name and HW version
drawing 0.00.07
2015-05-05 Dulce Tupino
• Accepted all the changes in the document
• Provided comments and suggestions
• Added Section 1.2 References (to be confirmed by the engineers)
0.00.08
2015-07-12 Bruce Wang
• Added firmware version display
• Revised the key table and key loading
• Added key replacement
• Added roles and service
• Comply with Modular Security Requirements V4.1 - 2015
1.00.09
2015-09-25 Bruce Wang • Modified according to 2nd review 1.00.10
2015-11-30 Bruce Wang • Added Roles
• Added minimal configuration 1.00.11
2016-02-15 Jack Tse • Update Figure 1 (Version label) 1.00.12
2016-02-25 Bruce Wang • Added OP protocol 1.00.13
2016-07-02 SK Au
• Added product picture
• Added section 4.3 Application development guidance
• Added section 4.4 Product Authentication
1.00.14
2016-08-04 Patrick Chu • Modified section 4.4 Product Authentication 1.00.15
2016-09-09 York • Modified HW/FW version accordingly 1.00.16
Page 3 of 22
Date By Changes Version
2016-12-14 York • Corrected typo in page 7 and footer 1.00.17
Page 4 of 22
Table of Contents
1.0. Introduction ................................................................................................................. 6
1.1. Symbols and Abbreviations 6
1.2. References 7
2.0. General Descriptions .................................................................................................. 8
2.1. Product Overview 8
2.2. Device Functionality 8
2.3. Product Identification 8
2.3.1. Hardware Information 8
2.3.2. Software Information 9
3.0. Installation Guidance ............................................................................................... 11
3.1. Installation Environment 11
3.2. Configuration Settings 11
3.3. Default Value Update 11
4.0. Secured Operation Guidance .................................................................................. 12
4.1. PIN Confidentiality 12
4.2. Periodic Security Inspection 12
4.3. Application development guidance 12
4.3.1. Methodology 12
4.3.2. Development and Review 13
4.3.3. Testing 13
4.3.4. Authorization 13
4.4. Product Authentication 13
4.5. Product Decommissioning/Removal 13
5.0. Product Software Security ....................................................................................... 14
5.1. Software Development Guidance 14
5.2. Firmware Signing/Authentication 14
5.3. Application Authentication 14
5.4. Software Update 14
5.5. Configuration Parameters Update 14
5.6. Device Self-Test 15
6.0. Product Hardware Security ..................................................................................... 16
6.1. Tamper Response Event 16
6.2. Environmental Conditions and Failure Protection 16
6.3. ICC Slot 16
7.0. Key Management ...................................................................................................... 17
7.1. Key Management System 17
7.2. Cryptographic Algorithms 17
7.3. Key Table 17
7.4. Key Loading Method 19
7.5. Key Replacement 19
7.6. Key Removal 19
8.0. System Administration ............................................................................................. 21
9.0. Roles and Services ................................................................................................... 22
List of Figures Figure 1 : Back side of ACR900 ............................................................................................................. 9
Page 5 of 22
List of Tables Table 1 : Symbols and Abbreviations ..................................................................................................... 6
Table 2 : Key Table ............................................................................................................................... 19
Page 6 of 22
1.0. Introduction This document serves as the ACR900 Security Policy which addresses the proper use of the POI in a secure manner, including information as below:
• Product overview
• Product identification
• Hardware/Software guidance
• Key management
• Environmental requirements
• PIN Confidentiality
• Decommissioning
The use of the terminal in an unapproved method, deviating from the methods, described in the security policy, will violate the PCI PTS approval of the device.
1.1. Symbols and Abbreviations
No. Abbreviations Description
1 PCI Payment Card Industry
2 PED PIN Entry Device
3 PIN Personal Identification Number
4 SCD Secure Cryptographic Device
5 MRK Maxim Root Key , owned by Maxim
6 CRK Customer Public Key
7 SHID Secure Human Input Device
8 AES Advanced Encryption Standard
9 RSA Rivest Shamir Adelman Algorithm
10 SHA Secure Hash Algorithm
11 TDES Triple Data Encryption Standard
12 DUKPT Derived Unique Key per Transaction
13 OTP One Time Programmable
14 ICC Integrated Circuit Card
15 MSR Magnetic Stripe Reader
16 PICC Proximity Integrated Circuit Card
Table 1: Symbols and Abbreviations
Page 7 of 22
1.2. References
[1] ANS X9.24-1:2009, Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques
[2] ANS X9.24 Part 2: 2006, Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for the Distribution of Symmetric Keys
[3] X9 TR-31 2010, Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms
[4] ISO 9564-1, Financial services — Personal Identification Number (PIN) management and security - Part 1: Basic principles and requirements for PINs in card-based systems
[5] ISO 9564-2, Banking — Personal Identification Number management and security Part 2: Approved algorithms for PIN encipherment
[6] PCI PTS POI Modular Security Requirements V4.1 - 2015
[7] ACR900-API Specification
Page 8 of 22
2.0. General Descriptions This document aims to provide indication to answer the security requirements as listed in DTR B20 in the PCI PTS POI Version 4.1.
2.1. Product Overview
The ACR900 is designed as handheld POS Payment Terminal Device to support PIN entry with credit and debit based transaction in attended environment.
This device provides the features as below
• TFT color LCD (240*320)
• Keypad (22 keys)
• ICC
• PICC
• MSR
• Build-in Thermal printer
• USB port
• RS-232 port
• Other communication peripheral: Ethernet, WiFi, GPRS.
2.2. Device Functionality
The handheld payment device supports PIN entry, MAC calculation, encryption/decryption related to EMV chip, contactless EMV chip and Magnetic stripe card transaction. This machine provides a complete portfolio of connectivity to USB host/device, Serial port, Ethernet, WiFi and GPRS.
It is forbidden to use in an unattended environment, use of device in an unattended environment will violate the PCI PTS approval of the device.
The firmware system configurations are minimal, and necessary to meet the security requirement.
2.3. Product Identification
2.3.1. Hardware Information
The device name is printed top right side of LCD display and hardware version in the label attached to bottom case.
The product name and hardware version are also printed on a label at the back of the device. The label at the back of the device shall not be teared off, covered or altered.
Page 9 of 22
• Product Name: ACR900
• Hardware Version : 4.00.11
Figure 1: Back side of ACR900
2.3.2. Software Information
Firmware version can be retrieved from System Manager Menu by following operations:
1. System Menu
2. System Config
3. Hardware & Software Version
Page 10 of 22
User should check software and firmware version of the device at field
Page 11 of 22
3.0. Installation Guidance The ACR900 is designed to be portable.
An installation guide including the following information is provided with the device:
Equipment check list:
� Device,
� Cable and connectors,
� Documents
Power and cable connections information,
The main characteristics of the device(i.e. temperature, humidity, voltage)
Security recommendations,
Troubleshooting if the device does not work.
3.1. Installation Environment
The device is designed to be used in an attended environment.
Operating Temperature: 0 °C ~ 50 °C
3.2. Configuration Settings
The security functions are an inherent part of firmware functions. And the firmware does not use any security sensitive configuration setting.
3.3. Default Value Update
The device is distributed to acquirer with default passwords to access of key injection. The default passwords are informed to acquirer by training. The default passwords are pre-expired and have to be updated as following operation:
The device does not include any certificate for testing purpose.
When the end user receives the device from acquirer, there is no sensitive default value which is necessary to be changed before operation.
Page 12 of 22
4.0. Secured Operation Guidance
4.1. PIN Confidentiality
The customer must enter the PIN safely. It is recommended that the position of the terminal on check-stand must in such a way to make cardholder PIN spying infeasible. The customer should be advised to ensure that he is not spied upon entering his PIN. One way to assure PIN-entry privacy is through the inclusion of logos and guidance messages in the payment application for the cardholder’s references.
Logos and guidance message should be easy to understand and should instruct cardholders on how to protect the PIN from being espied, such as by using cardholder’s body or free hand to block a keypad during PIN entry.
4.2. Periodic Security Inspection
The merchant/acquirer must visually inspect the terminal device everyday as what is described below:
1. Inspect whether the IC card reader’s slot has untoward obstructions or suspicious objects at the opening;
2. Inspect whether the MSR card slot has an additional card reader and other inserted bugs;
3. Inspect whether the product appearance has been changed to make sure that no any tamper evidence.
4. Power on the device and check if the firmware runs well. The start-up will inspect the hardware security, authenticity and integrity of firmware. Such checks would provide warning of any unauthorized modifications to or substitution of the terminal, or suspicious behavior of individuals that have access to the terminal.
5. Check if the firmware version is correct.
4.3. Application development guidance
4.3.1. Methodology
Secured application development procedures should be defined, implemented and maintained to ensure any security threats are mitigated. Below shows the methodology for application development.
Page 13 of 22
4.3.2. Development and Review
Application developer should follow the guidance provided in document <02-DSP-ACR900_Security_Guidance> when developing the application for the device. The source code of the developed application should be firstly reviewed according to the guidance provided in document <02-DSP-ACR900_Security_Guidance>.
4.3.3. Testing
The built application should be tested before using in the device. Testers should define test cases and security test plan to ensure the function and security of the application. Test report should be signed off by Application Development Manager. Please refer to document <02-DSP-ACR900_Security_Guidance> for detailed procedure.
4.3.4. Authorization
Application should only be released if the application is tested and approved by Application Development Manager. Application version number should be incremented for each time of release of new version of application to ensure the uniqueness of the application. Details please refer to document <02-DSP-ACR900_Security_Guidance>.
4.4. Product Authentication
When the acquirer/merchant/user has received the device via shipping, he or she should visually inspect below items in light environment or using light source to authenticate the device:
- Inspect the label at the back of the device to make sure that it is in good status and without any modifications. Then check the back label to make sure that its content shows the right product name and hardware version.
- Inspect the appearance of the device to make sure that no any modifications, damages, or evidences of cutting and adhesive applied to the device.
- Inspect ICC card slot to make sure that no any inserted bugs or evidences of unusual wires applied at the opening
- Inspect MSR slot to make sure that no any inserted bugs or additional reader
- Power on the device and check if the firmware runs well. The device start-up will inspect the hardware security, authenticity and integrity of firmware. Such checks would provide warning of any unauthorized modifications to or substitution of the device, or suspicious behavior of individuals that have access to the device.
- Check if the firmware version is correct.
4.5. Product Decommissioning/Removal
When the device is no longer used for permanent decommissioning reason, the administrator of the device needs to gather the device and then erases all the key materials on it. It can be done by directly disassembling device to make it tampered or using a dedicated tool to delete all sensitive information actively.
When the device requires temporary removal, there is no need to change the state of the device, as all the keys are still protected safely with the main board battery power supply.
Page 14 of 22
5.0. Product Software Security
5.1. Software Development Guidance
ACS provides software programming guide to developers to develop applications compliant with PCI security requirement.
When developing IP enabled applications, the developer must use the specified functions shid_iptables_reset and shid_iptables_tcp_enable which are mentioned in the document <ACR900 API Reference Manual>. It is not allowed to use the iptables directly.
The document <ACR900 API Reference Manual> describes how protocols and services must be used/configured for each interface that is available on the platform, including,
� The requirement for acquirer and software developer.
� The functions certified by PCI PTS.
ACR900 firmware/application implements the required security measures with functions to compliant PCI security requirements for authenticated applications.
This <ACR900 API Reference Manual> describes details of functions and parameters available on the ACR900 platform. Developers must use APIs to access sensitive services provided by ACR900, for example, ucl_sha256_whitening_rng_read.
5.2. Firmware Signing/Authentication
Firmware is signed in SCD under dual control. Asymmetric cryptographic algorithm is used for the firmware authentication:
• SHA256 is used to compute the digest of firmware
• RSA 2048 bits key is used for signature verification
The firmware is signed by RSA-2048 bits private key. This signer key is only controlled by ACS and the firmware authentication is done by signature verification using corresponding public key of ACS.
ACR900 firmware, user public key, application is signed under dual control in secure environment before released.
5.3. Application Authentication
Application code is authenticated before being allowed to run. The signature of the application code is verified. In case of incorrect signature, the update is rejected. No action is expected from the end user.
Application must be signed in SCD under dual control before download.
5.4. Software Update
ACR900 terminal will only accept signed software download and update via special tool with authorization. The software is digitally signed with RSA private key on SCD side before it is downloaded, and the download process is cryptographically authenticated by the device. If the authenticity is not confirmed, the update will be rejected, and the downloaded application will be deleted.
Note: Tampered devices will appear as disabled, and will not allow for firmware update and user software to run even if it's authentic.
5.5. Configuration Parameters Update
The device supports local update of configuration parameters. Any updates loaded into ACR900 must be signed, the configuration file is signed with dual control by ACS.
Page 15 of 22
5.6. Device Self-Test
The device will perform self-test upon startup and also every 24 hours. Periodical self-test is done by automatic reboot. This reboot period is counted up once the device is powered on. During self-test, the device performs verifying integrity and authenticity of the software with checking hardware security status. If the self-test fail, the device goes in out of service state and handles it same as hardware tamper attack.
Self-test includes:
• Check of the hardware security status, including tamper
• Check of integrity and authenticity of the firmware, cryptographic keys and application
Once any failures are detected in process of self-test, device will show the warning message, and switch the status to inactive mode. All operations will be forbidden in this status.
Page 16 of 22
6.0. Product Hardware Security
6.1. Tamper Response Event
1. The device contains tamper mechanism. In the event of tamper detection, the device will enter disable state. In the tampered / disabled state, the device clears the Root Key, clears secret keys, displays a warning message and further use of the device is not possible.
2. Stop using the terminal and report immediately to the terminal service partners or directly to ACS Service Center for checking and repairing when the device was tampered.
6.2. Environmental Conditions and Failure Protection
ACR900 targets to be used in attended environment while the security of the device is not compromised by altering the environment condition such as temperature, operating voltage outside and etc.
Operation Temperature: 0 °C ~ 50 °C
Operation Relative humidity : 10% - 90%
Storage Temperature: -20 °C ~ 60 °C
Storage Relative humidity : 5% - 95%
The security of the device is not compromised by altering environmental and operational conditions, includes temperatures and voltages outside the stated ranges.
Low High Temperatures Monitor
-35°C 125°C Vcore Voltage Monitor 0.82V~0.95V 1.25V~1.4V Vio Voltage Monitor 2.8V~3V 3.8V~4.2V Vbat Voltage Monitor 2.1V~2.3V 3.8V~4.2 V
• If your environment status is over that range, the terminal is not always working.
• If you can see warning message “Tamper detected!”, please contact ACS Agency or authorized service agent.
6.3. ICC Slot
Before using chip card for ICCR, you must check the device’s status daily inspection in light environment or using light source. Please refer as below suggested steps:
1. First check outside enclosure if it is the right product. No modification, no damage, no evidence of cutting and adhesive.
2. Check no evidence of unusual wires that has been connected to ICCR inside.
3. There is no shim device in the slot of ICC acceptor.
4. There is no resistance or loosing when inserting the card.
5. Inserted card direction is parallel with LCD.
6. When the card is inserted into the exposed portion of the card in the direction of its half size.
Such checks would provide warning of any unauthorized modifications to or substitution of the terminal, or suspicious behavior of individuals that have access to the terminal.
Page 17 of 22
7.0. Key Management
7.1. Key Management System
For symmetric keys, three types of key management techniques are supported, including:
1. Fixed key: Unique key for each terminal.
2. Master/Session key: Hierarchy of keys.
3. DUKPT: Unique key for each transaction.
ACR900 uses key bundling technique key derivation method from ANSI TR-31 2010 for key loading.
All keys in these key management techniques are stored in cipher-text under the protection of key encryption key Root Key. The Root Key is stored in CPU battery backed-up register.
Asymmetric keys are used for firmware authentication and application authentication.
When performing self-testing during manufacturing, if KCUSTOMvpub is not loaded into ACR900, a “DEMO” watermark is always displayed on screen to distinguish normal payment application.
Use of the terminal with a key-management system other than the three mentioned above will invalidate any PCI approval of the terminal.
7.2. Cryptographic Algorithms
The device implements following algorithms:
1. AES (128 bits and 256 bits)
2. RSA (Signature verification, 2048 bits)
3. SHA-256 (Signature digest)
4. TDES (112 bits)
7.3. Key Table
Key name Purpose Algorithm
Size Generated By
Factor Loaded to Device In storage
KBPK (Key Block
Protect Key)
Encryption of
TMK, IPEK and Fixed
Key
TDES
112 bits
Acquirer Using TR-31 during key injection, loaded directly in secure environment with dual control. Encrypted with Rootkey stored in NVSRAM.
NVSRAM
TMK (Terminal
Master Key)
Encryption of session keys for
transmission to the device
TDES
112 bits
Acquirer Encrypted with KBPK using TR-31 during key injection, loaded directly in secure environment. Encrypted with Rootkey stored in
NVSRAM.
NVSRAM
MACK (SK-MAC
Key)
Message Authenticati
on
TDES
112 bits
Acquirer Encrypted with TMK using TR-31 during key injection.
Encrypted with Rootkey stored in NVSRAM.
NVSRAM
PEK （SK-PIN
Encryption Key ）
PIN Encipherm
ent of online PIN
TDES
112 bits
Acquirer Encrypted with TMK using TR-31 during key injection.
Encrypted with Rootkey stored in NVSRAM.
NVSRAM
Page 18 of 22
PANK (SK-PAN
data Encryption
Key)
Encipherment of PAN
data
TDES
112 bits
Acquirer Encrypted with TMK using TR-31 during key injection.
Encrypted with Rootkey stored in NVSRAM.
NVSRAM
Root Key Encryption of all keys
and password
AES 256 bits
Manufacturer
Generated by MAX32590 cpu(MAX32590) battery backed
AES key
register
Fixed Key (FK-PEK,
FK-MACK, FK-PANK)
PIN and PAN data Encipherm
ent for online ,and Message
Authentication
including(FK-PIN key/ FK-MAC key/FK-
PAN key)
TDES
112 bits
Acquirer Encrypted with KBPK using TR-31 during key injection, loaded directly in secure environment. Encrypted with Rootkey stored in
NVSRAM.
NVSRAM
IPEK DUKPT Initial Key
TDES
112bits
Acquirer Encrypted with KBPK using TR-31 during key injection, loaded directly in secure environment. Encrypted with Rootkey stored in NVSRAM.
Stored in RAM
and then
erased after
generating 21
current keys
DUKPT CK
(Current Key)
PIN and PAN data Encipherm
ent for online and Message
Authentication
TDES
112bits
Acquirer Derived originally from IPEK NVSRAM
KCUSTOMvpub
This key is used for verifying the certificate of KAPPvpub when KAPPvpub is loaded
RSA
2048 ACS This key is generated by ACS and signed by ACS with ACSspriv.
NAND flash
Page 19 of 22
KAPPvpub This key is used for the verification
of the signature of the Applications when application start up
RSA 2048 acquirer
Generated by acquirer and signed by ACS with KCUSTOMspriv
NAND flash
Table 2: Key Table
Cryptographic keys must be used only for their sole intended purpose.
• For example: A cryptographic key used for PIN encryption must not be used for message authentication.
• A PIN key must only ever be used for PIN encryption.
Device doesn't have any default secret keys at the beginning. Acquirer has to generate and inject all transaction keys before deploying. Each key should be used for specified purpose, and refused to export by any way. Acquirer should use Key Diversification technique to generate secret keys, ensure key uniqueness per device, and obliged to use the random number API provided by firmware of ACR900.
Any violation will invalidate the approval of this device.
7.4. Key Loading Method
ACR900 supports local key injection via USB interface, does not support remote key injection via Open Protocol.
The device does not propose manual cryptographic key entry and remote key injection. The key loading device SCD, which is complied with PCI PTS requirement, shall be placed in a secure environment and used for initial key injection.
The keys loading process must be implemented in a secure of acquirer and strictly protected under dual control.
1. KBPK initially loaded in plaintext on device, under Dual Control in secure environment.
2. All other keys (including MK, Fixed Key and DUKPT Initial Key) then loaded under symmetric key (KBPK).
3. Keys used for PIN/MAC functions are loaded as session keys on device, encrypted by a previous loaded acquirer master key.
The key loading method for application is TR31 (Binding Method) specified in document [3].
Before loading application, user public key KCUSTOMvpub has to be loaded into device using ACS loading tool.
7.5. Key Replacement
Any keys should be replaced with a new key value whenever the compromise of the original key is known or suspected, and whenever the time deemed feasible to determine that the key by exhaustive attack elapses.
7.6. Key Removal
• If tamper event is detected, the key encryption key Root Key in the device will be erased automatically.
Page 20 of 22
• Once the keys are loaded to device successfully, they will be available unless the administrator wants to erase all keys for some reason like decommissioning or when a tamper issue is detected.
• If one key has been COMPROMISED, this key and its derived keys should not be used any more. User can use another working key which is not derived from the compromised key is still safe. But if the device is tampered, it’s requested to send the device to an authorized service center for repair and re-download the new keys.
Page 21 of 22
8.0. System Administration 1. The acquirer needs to ensure no sensitive security configuration setting is required by the
merchant.
2. Sensitive data in the device has to be deleted before refurbishing or removing device from service. If device is tampered, all sensitive data will be erased automatically.
3. No person shall keep more than one password.
4. Open protocol
In current version of the device, all open protocols modules and Ethernet interface have been disabled in firmware. Software guidance for open protocols will be added in future release of security policy document.
Page 22 of 22
9.0. Roles and Services The customers of ACS are acquirer. ACS sells devices to acquirer and provides technical support and maintenance. Acquirer sells the devices to end users and provides services their end user.
ACS, acquirer and end users play different roles in operating the device. Below table shows different roles and operations:
Name Role Operation
Acquirer administrator 1.Organize third party to develop payment application program;
2.Sign and download customer public and application;
3.Access to device sensitive service
End user operator Perform transaction
ACS maintainer 1.Sign firmware in SCD and initial loading;
2.Sign customer public key;
3.Repair device and unlock the device if tampered
