Using OSDP

OSDP is the Open Supervised Device Protocol, which defines a method for secure communication between an Access Control Unit (ACU) and all its Peripheral Devices (PDs), such as the VTAP reader. In this protocol the ACU is always primary and the PDs are subordinate devices.

The VTAP reader Command Interfaces are set up as human interfaces. Using the secure OSDP protocol on interfaces provides an ideal machine interface with the necessary CRCs and integrity checks.

There are four OSDP profiles - Basic, Secure, Smartcard and Biometric. VTAP readers support only the first two of these:

Basic - which provides a direct Wiegand alternative, to send credentials and control simple LED or buzzer feedback. Credentials are passed in ASCII or raw (Wiegand) format, as a binary number comprised of a bit count and bit stream.
Secure - which uses an AES 128bit key stored in one of the VTAP reader encryption key slots. Secure includes all the features of Basic with the addition of a secure communications channel.
Smartcard (not supported by VTAP) - is intended to allow secure information to be sent between ACU and smartcard without action from the intervening reader. This creates a set up similar to a VPN, intended to support security challenges, for example when using US PIV cards.
Biometric (not supported by VTAP) - extends the smartcard functionality to the secure transmission of fingerprint and other templates between ACU and biometric device without action from the intervening reader.

Initialisation

Normally, an initial request for data from a PD will be made by the ACU. It will retrieve basic information, such as the device number, IEEE vendor number and its capabilities. If a secure channel is required, the shared key can either be preloaded into one of the 9 app key slots on the VTAP reader or, if supported by the ACU, it can be generated and set by the ACU on first use. The key is needed to set up a secure channel. When the OSDP key slot in the VTAP reader is empty, it is in "initialisation mode" and the default Secure Channel Base Key (SCBK-D) will be used. Any new Secure Channel Base Key (SCBK) set by the ACU (using the osdp_KEYSET command) will always overwrite the one being used to support OSDP at that point. The ACU can change this key as often as it likes.

It is an assumption in the OSDP standard that this initialisation will happen on a short cable connection, where the ACU and PD can both be seen and trusted at the time an initial key is shared.

Secure mode only

To ensure that secure communications remain secure whenever you use OSDP, it is possible to use settings on the VTAP reader (see Serial2OSDPSecureOnly in Send pass payload using OSDP over an RS-485 interface) to require that only the Secure profile is used, after initialisation. If this is not done, it is possible that the implementation of OSDP on the ACU would allow its PDs to fall back to using the Basic profile if Secure credentials failed.

File transfer mechanism

OSDP can be used to send firmware updates or transfer other files (config.txt, encryption keys, keyboard maps etc) securely. This relies on VTAP reader files having assigned numerical IDs to identify the purpose of the data, used in place of filenames.

These file numbers are specified by the FtType parameter within the osdp_FILETRANSFER command. The numbers 2 to 127 are reserved in the OSDP specification v2.2 for future use. The VTAP OSDP implementation therefore uses the range of numbers reserved for private use 128 to 255.

VTAP filename	`FtType` in `osdp_FILETRANSFER`	VTAP filename	`FtType` in `osdp_FILETRANSFER`
CONFIG.TXT	128	APPKEY1.TXT	141
VTAPWARE.DAT	129	APPKEY2.TXT	142
PRIVATE1.PEM	130	APPKEY3.TXT	143
PRIVATE2.PEM	131	APPKEY4.TXT	144
PRIVATE3.PEM	132	APPKEY5.TXT	145
PRIVATE4.PEM	133	APPKEY6.TXT	146
PRIVATE5.PEM	134	APPKEY7.TXT	147
PRIVATE6.PEM	135	APPKEY8.TXT	148
		APPKEY9.TXT	149

OSDP custom Commands

OSDP permits the definition of a set of custom commands. The custom commands allow for control of many VTAP reader features that are not anticipated in the current version of OSDP. So custom commands are defined for the VTAP reader to permit a subset of its normal serial commands, for example to change to card emulation mode and set card emulation data.

Although LED on/off, timed LEDs and black, red, green, amber, blue, magenta, cyan, and white colours are supported by the VTAP reader, it does not currently support the full extent of osdp_LED control (for example switching between different on/off colours). Anything more complex than a simple beep and/or red LED, for example using any other RGB colour, will rely on use of a VTAP custom command.

The osdp_BUZ command is well supported by the VTAP reader, as it corresponds closely to the existing VTAP beep command.

VTAP commands permitted in OSDP mode

VTAP command interfaces can potentially be used for all of the usual VTAP serial commands, even when that the same interface has been assigned to OSDP mode. These potentially allow a host system not using OSDP to communicate with a VTAP over a communication channel that has been set to use OSDP. OSDP requests and standard VTAP (human readable) commands can co-exist on the same port.

For security reasons, when in secure only mode, only two of those VTAP serial commands are permitted: ?osdp will determine whether OSDP is active on an interface and ?b will find out whether secure only mode has been selected.

Although OSDP is often implemented over an RS-485 interface, the same protocol can be used over any VTAP reader serial interface.

RS-485 issues

RS-485 interfaces give rise to a number of potential issues. RS-485 relies on screened twisted pairs of cables, for which a common ground is essential. If modern equipment is used, including slew‑rate limited transceivers, operating at low voltage and high impedance, there is no need for terminating resistors, which can limit the number of PDs that can be daisy‑chained.