Hardware data sheet

IPOS bric Hardware Data Sheet – Version

Product Overview

This document addresses the proper use of IPOS bric in a secure manner including information about key-management responsibilities, administrative responsibilities, device functionality, identification and environmental requirements.

Failure to use of the device in accordance with this security policy will violate its PCI PTS 5.x compliance and approval.


This guide provides simple descriptions of IPOS bric features, as well as basic information for anyone installing and configuring IPOS bric.


AES Advanced Encryption Standard COTS Commercial off-the-shelf Device DUKPT Derived Unique
Key per Transaction N/A Not Applicable
PED PIN Entry Device
PIN Personal Identification Number
RSA Rivest Shamir Adelman Algorithm SCRP Secure card reader – PIN
SHA Secure Hash Algorithm TDES Triple Data Encryption Standard

IPOS bric Product Description

The IPOS bric unit is a handheld SCRP with an integrated smart and contactless card reader, offering advanced security and payment processing capabilities to handle credit and debit card transactions in an attended environment.

IPOS bric supports both symmetric encryption algorithms (3DES and AES) and asymmetric encryption (RSA). This device internally manages simultaneous multiple keys through either Fixed or DUKPT-based processes, and offers high performance smart card processing, as well as support for the new generation of 3-volt cards.

The IPOS bric sleek and stylish ergonomic design offers power and performance in a smart and contactless-integrated payment device.

Features and Benefits

Exceptional Ease of Use

Ergonomic design is sleek, stylish, and lightweight for conveniently handing the unit to the consumer.

Critical Security Protection

• Incorporates tamper-detection circuitry to resist unauthorized intrusion and supports a broad spectrum of hardware and software-based security features.
• Integrated security modules simultaneously support sophisticated encryption (AES, 3DES, RSA) and key management schemes.

Strong Feature Set

The IPOS bric is designed to handle all forms of payment including:
• EMV chip & Sign
• Contactless IPOS bric provides connectivity options: USB – Bluetooth Low Energy 4.2 (how to pair is describe in IPOS bric User Manual). The device does not support Beacons.

Hardware Security


Upon receiving the IPOS bric terminal, the merchant or acquirer must validate the shipment origin and sender name of the terminal to be genuine by verifying the courier tracking number and sender information located on the product order paperwork/invoice.

The terminal must be visually inspected for signs of tampering prior to placement in the field to ensure that the device has not been tampered with and is in its original pristine condition.

IPOS bric must be verified to be approved by PCI SSC as an SCRP on the official PCI PTS SSC portal: https://www.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices
• Locate the Product Identification Label on the back of the device and verify that the product name and hardware version number match the product name and hardware version number shown on the PCI PTS listing web site.
• Compare the first two digits of the Firmware version with the one listed in the PCI PTS listing web site.


The following inspections must be performed on a regular basis after initial receipt and installation of IPOS bric:
• First two LEDs on the front are not flashing continuously with a red light after powering on the device.
• There are no unusual wires connected to the ICC acceptor or any of the ports on the terminal.
• There is no shim device in the ICC acceptor slot.
• The terminal serial number(on the label) corresponds to the one in the inventory paperwork.

Suspicious behaviour of the terminal or suspicious behaviour of individuals that have access to the terminal: In the tampered state, the first two LEDs on the front are flashing continuously with a red light and the use of the device is not possible. If such state is observed, the merchant or acquirer must contact the terminal helpdesk immediately, remove it from service and keep it available for potential forensics investigation. The merchant or acquirer should also check that the periodic inspections and maintenance are performed by a trusted person and log the periodic checks and maintenance operations, including name of the operator.


Sensitive data must be erased before refurbishing the terminal or removing it permanently from service. The terminal shall go to tampered status, a state in which sensitive data is erased. Note: Disassembly of the device will lead to a tampered status.


The specified environmental conditions to operate and store the device are:

Operating: -10oC to +45oC / 5% to 90% RH Storage: -15oC to +55oC / 5% to 90% RH
For safe battery charging, we recommend from 0oC to +40oC / 5% to 90% RH

The security of the terminal is not compromised by altering the environmental conditions (e.g. subjecting the device to temperature or operating voltages outside the stated operating ranges does not alter the security). Any temperature or operating voltage, outside from the values in the table below, will result in a tamper condition:


The device contains tamper mechanisms that will trigger when a physical penetration attempt of the device is detected. A merchant or acquirer can easily detect a tampered terminal:
• The first two LEDs on the front are flashing continuously with a red light (Figure 4), during the booting a characteristic sound is played.

Any physical penetration will result in a “tamper event”. This event causes the activation of tamper mechanisms that make the device inoperable and out of service.

If the device is in tampered state, the merchant or acquirer should contact the terminal’s helpdesk
Temperature sensor: Voltage secsor
Min. value Max. value
-50C            +120C
2.3V             3.6V

Software Security

IPOS bric does not allow the execution of unauthorized or unnecessary functions.


When developing IP enabled applications, the developer must abide by the coding rules and best practices described in the Application Development Guidelines 4 document. The security guidance in the Application Development Guidelines 4 document describes how protocols and services must be used/configured for each interface that is available on the platform.

When developing applications, the developer must follow the guidance described in the Application Development Guidelines 4 document for procedural controls to ensure that the applications are properly reviewed, tested and authorized.

The document provides security guidance for account data management and remote connection authentication using cryptographic mechanisms.


Firmware and application images are signed by the Manufacture using different keys. The signing is performed in a secure room. Signing equipment consists of a special Hardware Secure Module, which requires dual control.

The cryptographic algorithms utilized for signing:
♣ RSA 2048, used for signature verification.
♣ SHA256, used for calculating a hash for data integrity.


Updates to the firmware and the application can be loaded in the device. They are cryptographically authenticated by the terminal. If the authenticity is not confirmed, the update is rejected. For secure operation of the device, it is recommended to always use the latest version of firmware distributed.


Application code is authenticated before being allowed to run. The signature of the application code is verified. In case of an incorrect signature, the update is rejected. No action is expected from the end user. The signature is based on the RSASSA-PKCS1-V1_5 SHA-256 algorithm and 2048 bit keys. The authenticity is guaranteed by the manufacturer.

PIN Confidentiality

The intended use of IPOS bric is as a handheld SCRP device in an attended environment. The mobile device (COTS) will be given to the customer to enter the PIN. The body of the customer and the orientation of the mobile device towards him will protect the PIN entered from visual observation.

Self-tests are performed upon start up/reset and also periodically once a day. These tests are not initiated by an operator. Self-tests include:
• Check of integrity and authenticity of the firmware, application and cryptographic keys • Check of the security mechanisms for sign of tampering

Key Management


The device does not support manual cryptographic key entry. Secure equipment, compliant with key management requirements (5,6,7,8,9) must be used for key injection.
Cryptographic Keys and credentials must be managed under dual control and split knowledge in order to prevent one person using two credentials simultaneously.

There are total 100 3DES/AES and DUKPT key slots available in the secure firmware of the terminal. The terminal supports two key loading methods:
• TR-31 Key Derivation Method7
• Custom Method – using Key Encryption Keys


• Encrypt/Decrypt Data
• MAC Calculation and Verification
• PIN Encryption 

PINs are encrypted using an algorithm and key size specified in ISO 9564.
The algorithm for online PIN is the TDEA using the electronic code book (TECB) mode of operation as described in ANSI X9.65.

The device implements three different PIN encryption key-management methods: Fixed Key, Master Key/ Session Key, DUKPT, as specified in ANSI X9.24 ISO 9564-1 PIN block formats 0, 3 or 4. Format 2 is used for offline PIN (contact EMV only)


The device supports the following algorithms: 3DES, AES, RSA, SHA


Key replacement must be performed upon any known or suspected compromise of any cryptographic or sensitive information. Any key should be replaced with a new key whenever the compromise of the original key is known or suspected, and whenever the time deemed feasible to determine the key by exhaustive attack elapses. The key replacement can be performed only by the manufacturer.

Terminal Administration


The device is functional when received by the merchant or acquirer. No security sensitive configuration settings are necessary to be tuned by the end user to meet security requirements.


The device is fully functional when received by the merchant or acquirer and there is no security sensitive default value that needs to be changed before operating the device.


The device has no functionality that gives access to security sensitive services, based on roles. Such services are managed through dedicated tools, using cryptographic authentication.