Innovative NV9 Manual

SSP SMILEY®
SECURE
PROTOCOL
INTELLIGENCE IN VALID
A
SSP SMILEY®
SECURE
PROTOCOL
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol 2
CHANGE HISTORY
Innovative Technology Ltd
Title: SSP Gaming Protocol
Drawing No: GA138 Project:
Author: P. Dunlop Date: 26/05/98
Format: MS Word 2000
Issue Protocol Ver.
Release Date
Mod By
Comments
Issue 1 1 26/05/98 PD
Issue 2 1 03/02/99 TB
Issue 3 1 11/06/99 AK
Issue 4 2 4/02/00 PD
Issue 5 2 20/06/00 PD
Issue 6 2 26/10/00 PD
Issue 7 2 20/11/00 PD
Issue 8 2 20/01/01 TB
Issue 9 2 4/10/01 TB
Issue 10 2 21/01/02 AK
Issue 11 2 23/03/04 PK General Revision
Issue 12 3 05/08/04 TB Protocol Version 3
Issue 13 3 02/01/06 TB Protocol Version 3 events
Issue 14 4 16/11/07 TB BNV Barcode commands
Issue 14G4 PD Encryption, Smart Range
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol
3
Issue 4. – Peter Dunlop 13/01/2000
Introduction of generic commands. Introduction of commands/ responses for coin readers
and coin hoppers. Introduction of addressing structure. Introduction of encrypted packets.
Upgrade “Protocol Version’ to 2.
Issue 5. – Peter Dunlop 20/06/2000
Clarification of remote download specification – addition of example sequences. Correction
of command conflict – SYNC and LAST REJECT CODE specified with same code, LAST
REJECT CODE has been changed to 0x17. Addition of notes to identify function not currently
implemented on NV4 / NV4X.
Issue 6. – Peter Dunlop 26/10/00
Block size missing from header description in version 5 – fixed. Rewording of description of
remote downloading protocol. Addition of maximum block size. No code changes required
in product firmware or demo code. Changed example CRC code from assembler example to
C example. Addition of simplified remote programming flow chart.
Issue 7. – Peter Dunlop 20/11/00
Introduction of basic card reader commands. Addition of FAIL as a generic response.
Addition of manufacturers extension generic command for use internally.
Issue 8. – Tim Beswick 20/01/01
Change SLAVE_RESET form generic response to an event response to reflect correct
behaviour. Addition of euro county code to appendix.
Issue 9. – Tim Beswick 04/10/01
Addition of HOLD command to allow escrow implementation on BNV
Issue 10. – Andrew Kennerley 21/01/02
Addition of slave address for a Audit Collection Device.
Issue 11. – Peter King 23/03/04
General Revision Correction of Slave ID Reference in section 3.1
Addition of extra address allocation for note validators
Issue 12. – Tim Beswick 05/08/04
Addition of SHOW_RESET_EVENTS BNV commands and note cleared at reset events.
Protocol taken to Version 3
Issue 13. – Tim Beswick 02/01/06
Addition of Cash box removed and replaced events. Explanation of Note start-up events in
expanded protocol.
Issue 14. – Tim Beswick 16/11/07
The addition of Bar code ticket commands and events for Banknote validator. Updated
reject reason codes.
Issue 14G. – Peter Dunlop 5/1/09
Revision of Encryption layer to propose a more secure system & interface for smart payout.
Commands that must be encrypted on encryption-enabled products are highlighted in red.
Copyright Innovative Technology GA138 –14G

Copyright Innovative Technology GA138 –14G
TABLE OF CONTENTS
Change History
2
1 Introduction 5
2 General description 6
3 Hardware Layer 7
4 Transport Layer 8
4.1 Packet Format 8
4.2 Packet Sequencing 8
5 Encryption Layer (currently not implemented) 9
5.1 Packet Format 9
5.2 Encryption Keys 10
5.3 Encryption Algorithm 11
6 Control Layer 12
6.1 Introduction 12
6.2 Addressing 12
6.3 Peripheral Validation 12
6.4 Generic Commands and Responses 13
6.4.1 Generic Commands 13
6.4.2 Generic Responses 14
6.4.3 Remote Programming (version 2.65 and later) 14
6.4.4 Example Programming File Formats (ITL NV4 Validator) 16
6.4.5 Simplified Remote Programming Flow Chart 17
6.5 Banknote Validator 18
6.5.1 BNV Operations 18
6.5.2 BNV Commands 18
6.5.3 BNV Response to Polls 22
6.6 Coin Acceptor 23
6.6.1 perationCoin Acceptor O 23
6.6.2 Coin Acceptor Commands 23
6.6.3 Coin Acceptor Responses to Polls 25
6.7 Single Coin Hopper 25
6.7.1 perationsSingle Coin Hopper O 25
6.7.2 Single Coin Hopper Commands 25
6.7.3 Single Coin Hopper Responses to Polls 26
6.8 Basic Card Reader 27
6.9 Smart Hopper – provisional, subject to change 27
6.9.1 Smart Hopper Operation 27
6.9.2 Smart Hopper Commands 27
6.9.3 Smart Hopper Responses to Polls 29
6.10 Smart Payout – provisional, subject to change 30
6.10.1 Smart Payout Operation 30
6.10.2 Smart Payout Commands 30
6.10.2.1
SMART Mode Commands 31
6.10.2.2
DUMB Mode Commands – Not recommended 31
6.10.3 Smart Payout Responses to Polls 32
Appendix A – Country Codes 33
Appendix B – Block Encryption Routines 34
Appendix C – CRC Calculation Routines 35
SSP® Smiley Secure Protocol 4

Copyright Innovative Technology GA138 –14G
1 INTRODUCTION
This manual describes the operation of the Smiley®Secure Protocol - SSP as fitted with
manual as there are many new features permitting
anual please contact the ITL for assistance. In
sted by contacting: support@innovative-
miley® and the ITL Logo are international registered trademarks and they are the
ean and International Patents and Patents
novative Technology is not responsible for any loss, harm, or damage caused by the
Firmware Version 1.10 or greater.
L recommend that you study thisIT
new uses and more secure applications.
you do not understand any part of this mIf
this way we may continue to improve our product. Alternatively visit our web site at
www.innovative-technology.co.uk
nhancements of SSP can be requeE
technology.co.uk
S
property of Innovative Technology Limited.
nnovative Technology has a number of EuropI
Pending protecting this product. If you require further details please contact ITL®.
In
installation and use of this product. This does not affect your local statutory rights. If in
doubt please contact Innovative Technology for details of any changes
MAIN HEADQUARTERS
Innovative Technology Ltd
Derker Street – Oldham – England - OL1 4EQ
Tel: [phone] Fax: [phone]
E-mail: [email protected]
Web site: www.innovative-technology.co.uk
SSP® Smiley Secure Protocol 5

Copyright Innovative Technology GA138 –14G
2 GENERAL DESCRIPTION
a secure interface specifically designed by ITL®to
e all
he interface uses a master slave model, the host machine is the master and the
ata transfer is over a multi-drop bus using clock asynchronous serial transmission with
ach SSP device of a particular type has a unique serial number; this number is used to
.
mmands are currently provided for coin acceptors, note acceptors and coin hoppers. All
EATURES:
• Serial control of Note / Coin Validators and Hoppers
er
iation
BENEFITS:
• Proven in the field
t interfacing of transaction peripherals.
nes.
o help in the software implementation of the SSP, ITL can provide C Code, DLL controls
Smiley®Secure Protocol - SSP is
address the problems experienced by cash handling systems in gaming machines.
Problems such as acceptor swapping, reprogramming acceptors and line tapping ar
addressed.
T
peripherals (note acceptor, coin acceptor or coin hopper) are the slaves.
D
simple open collector drivers. The integrity of data transfers is ensured through the use of
16 bit CRC checksums on all packets.
E
validate each device in the direction of credit transfer before transactions can take place
It is recommended that the encryption system be used to prevent fraud through bus
monitoring and tapping. This is compulsory for all payout devices.
Co
current features of these devices are supported.
F
• 4 wire (Tx, Rx, +V, Gnd) system
• RS232 (like) - open collector driv
• High Speed 9600 Baud Rate
• 16 bit CRC error checking
• Data Transfer Mode
• Encryption key negot
• 128 Bit AES Encrypted Mode
• Simple and low cos
• High security control of payout peripherals.
• Defence against surrogate validator fraud.
• Straightforward integration into host machi
• Remote programming of transaction peripherals
• Open standard for universal use.
T
and Visual Basic applications on request. Please contact support@innovative-
technology.co.uk.
SSP®Smiley Secure Protocol 6

Copyright Innovative Technology GA138 –14G
3 HARDWARE LAYER
cter transmission based on standard 8-bit asynchronous data
.
e data format is as follows:
Encoding:NRZ
AUTION: Power to peripheral devices would normally be via the serial bus however
e
ECOMMENDED CONNECTORS
mmended the first is a 15 pin 0.1” pitch header (Molex
ote Acceptor Conne
e second is a 10-pin 0.1” dual row shrouded header with polarized slot. This is primarily
Communication is by chara
transfer. Only four wires are required TxD, RxD, +V and ground. The transmit line of the
host is open collector, the receive line of each peripheral has a 10Kohm pull-up to 5 volts
The transmit output of each slave is open collector, the receive input of the host has a
single 3k3 ohm pull-up to 5 volts.
Th
Baud Rate: 9600
Duplex: FullDuplex
Startbits:1
DataBits:8
Parity: none
Stopbits:2
C
devices that require a high current supply in excess of 1.5 Amps e.g. hoppers would b
expected to be supplied via a separate connector.
R
Two types of connectors are reco
22-01-2155), this is primarily for use on bank note acceptors (see table 1).
Table 1 – Bank N ctor Details
Th
for use with coin acceptors. The pin out is shown below (see table 2).
Table 2 – Coin Acceptor Connector Details
Pin Signal
Pin 1 TxD
Pin 5 TxD
Pin 6 Address 0 (currently not implemented)
Pin 12 GND
Pin 11 +12V
Link Pin 3 to Pin 8 ENABLE
Pin Signal
Pin
Signal
1 TxD 2 Reserved
3 RxD 4 Reserved
5 Address 0 6 Address 1
7 +12V 8 Ground
9 Address 2 Address 410
SSP® Smiley Secure Protocol
7

SSP® Smiley Secure Protocol 8
4 TRANSPORT LAYER
4.1 PACKET FORMAT
Data and commands are transported between the host and the slave(s) using a packet
format as shown below.
STD SEQ/Slave ID LENGTH
DATA
CRCL
CRCH
STX: Single byte indicating the start of a message - 0x7F hex.
SEQ/Slave ID: Bit 7 is the sequence flag of the packet, bits 6-0 represent the address of
the slave the packet is intended for, the highest allowable slave ID is 0x7D
LENGTH: The length of the data included in the packet - this does not include STX, the CRC
or the slave ID.
Slave ID: Single byte used to identify the address of the slave the packet is intended for.
DATA: Commands or data to be transferred.
CRCL, CRCH: Low and high byte of a forward CRC-16 algorithm using the Polynomial (X16
+ X15 + X2+1) calculated on all bytes, Except STX. It is initialised using the seed 0xFFFF.
The CRC is calculated before byte stuffing.
4.2 PACKET SEQUENCING
Byte stuffing is used to encode any STX bytes that are included in the data to be
transmitted. If 0x7F (STX) appears in the data to be transmitted then it should be
replaced by 0x7F, 0x7F.
Byte stuffing is done after the CRC is calculated, the CRC its self can be byte stuffed. The
maximum length of data is 0xFF bytes. The sequence flag is used to allow the slave to
determine whether a packet is a re-transmission due to its last reply being lost.
Each time the master sends a new packet to a slave it alternates the sequence flag. If a
slave receives a packet with the same sequence flag as the last one, it does not execute
the command but simply repeats its last reply.
In a reply packet the address and sequence flag match the command packet. This
ensures that no other slaves interpret the reply as a command and informs the master
that the correct slave replied.
After the master has sent a command to one of the slaves, it will wait for 1 second for a
reply. After that, it will assume the slave did not receive the command intact so it will re-
transmit it with the same sequence flag.
The host should also record the fact that a gap in transmission has occurred and prepare
to poll the slave for its serial number identity following the current message. In this way,
the replacement of the host’s validator by a fraudulent unit can be detected.
The frequency of polling should be selected to minimise the possibility of swapping a
validator between polls. If the slave has not received the original transmission, it will see
the re-transmission as a new command so it will execute it and reply. If the slave had seen
the original command but its reply had been corrupted then the slave will ignore the
command but repeat its reply. After twenty retries, the master will assume that the slave
has crashed.
A slave has no time-out or retry limit. If it receives a lone sync byte part way through
receiving a packet it will discard the packet received so far and treat the next byte as an
address byte.
Copyright Innovative Technology GA138 –14G

5 ENCRYPTION LAYER
5.1 PACKET FORMAT
Encryption is mandatory for all payout devices and optional for pay in devices. Encrypted
data and commands are transported between the host and the slave(s) using the
transport mechanism described above, the encrypted information is stored in the data
field in the format shown below (see figure 1).
STX SEQ/Slave ID LENGTH
DATA
CRCL
CRCH
STEX Encrypted Data
LENGTH DATA PACKING CRCL CRCH
Figure 1 – Encrypted Data Format
STEX: Single byte indicating the start of an encrypted data block - 0x7E hex.
LENGTH: The length of the data included in the packet - this does not include STEX, the
next key or the CRC.
PACKING: Random data to make the length of the length +data +packing +CRCL +CRCH
to be a multiple of 16 bytes. There must be at least one random packing byte in each
pocket.
CRCL, CRCH: Low and high byte of a forward CRC-16 algorithm using the polynomial (X16 +
X15 + X2+1) calculated on all bytes, except STEX. It is initialised using the seed 0xFFFF.
After power up and reset the slave will stay disabled and will respond to all commands
with the generic response Key_Not_Set, without actioning the command, until the key
has been negotiated.
There are two classes of command and response, general commands and commands
involved in credit transfer. General commands may be sent with or without using the
encryption layer. The slave will reply using the same method, unless the response
contains credit information, in this case the reply will always be encrypted. Credit
transfer commands, a hopper payout for example, will only be accepted by the slave if
received encrypted. Commands that must be encrypted on an encryption-enabled
product are highlighted in red throughout this document. The STEX byte is used to
determine the packet type. Ideally all communications will be encrypted.
After the data has been decrypted the CRC algorithm is preformed on all bytes including
DATA, CRCL and CRCH. The result of this calculation will be zero if the data has been
decrypted with the correct key. If the result of this calculation is non-zero then the
peripheral should assume that the host did not encrypt the data (transmission errors are
detected by the transport layer). The slave should go out of service until it is reset.
SSP® Smiley Secure Protocol
9
Copyright Innovative Technology GA138 –14G

5.2 ENCRYPTION KEYS
The encryption key is 128 bits long, however this is divided into two parts. The lower 64
bits are fixed and specified by the machine manufacturer, this allows the manufacturer
control which devices are used in their machines. The higher 64 bits are securely
negotiated by the slave and host at power up, this ensures each machine and each
session are using different keys. The key is negotiated by the Diffie-Hellman key
exchange method. See: http://en.wikipedia.org/wiki/Diffie-Hellman. The exchange
method is summarised in the table below. C code for the exchange algorithm is
available from ITL.
Host Slave
1 Generate prime number GENERATOR
2 Use command ‘Set Generator to
send to slave
3 Check GENERATOR is prime and store
4 Generate prime number MODULUS
5 Use command ‘Set Modulus’ to send
slave
6 Check MODULUS is prime and store
7 Generate Random Number
HOST_RND
8 Calculate HostInterKey: =
GENERATOR ^ HOST_RND mod
MODULUS
9 Use command ‘Request Key
Exchange’ to send slave
10 Generate Random Number SLAVE_RND
11 Calculate SlaveInterKey: = GENERATOR
^ SLAVE_RND mod MODULUS
12 Send to host as reply to ‘Request Key
Exchange’
13 Calculate Key: = SlaveInterKey ^
HOST_RND mod MODULUS
Calculate Key: = HostInterKey ^
SLAVE_RND mod MODULUS
Note: ^ represents ‘to the power of’
Action Command Code (HEX)
Set Generator 0x4A, Generator
Set Modulus 0x4B, Modulus
Request Key Exchange 0x4C, HostInterKey
Table 1 – Encryption Control Commands
SSP® Smiley Secure Protocol 10
Copyright Innovative Technology GA138 –14G