For the complete documentation index, see llms.txt. This page is also available as Markdown.
Page cover

Application Group 0x02 - Authentication Messages

Command 0x02::0x0A - EPP Pairing Certificate Exchange

This command starts the EPP pairing process on oDynamo using the results from the START_EXCHANGE command on the Encrypting PIN Pad (EPP). The host should use the oDynamo response as the parameters for the next EPP command GENERATE_KEK. For details about the pairing flow, see Appendix G How to Pair With a Cryptera Encrypting PIN Pad.

Table - Message Structure for Command 0x02::0x0A - EPP Pairing Certificate Exchange

Tag

Len

Value(s) / Description

C0

01

01

Message Type Data Object (Tag C0) = 0x01 Command

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

0B

Command ID Data Object (Tag C2) = 0x0A EPP Certificate Exchange

C4

Calculated

Data Field Data Object (Tag C4 or E0) =

Use complete response to the EPP START_EXCHANGE command when the response code indicates OK (first 4 bytes should be 00020000).

If an error occurs, the device will terminate the command and report the error using an ACK Response containing the result code. For a full list of error codes, see 2.4.4 Result Code Data Object (Tag C3). If no error occurs, the device responds as follows:

Table - Response to Command 0x02::0x0A - EPP Pairing Certificate Exchange

Tag

Len

Value(s) / Description

C0

01

02

Message Type Data Object (Tag C0) = 0x02 Response

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

0B

Command ID Data Object (Tag C2) = 0x0A EPP Certificate Exchange

C3

01

00

Result Code Data Object (Tag C3) = 0x00 OK / Done

C4

Calculated

Data Field Data Object (Tag C4 or E0) =

Provide this data as the parameter portion of the EPP GENERATE_KEK command.

Command 0x02::0x0B - Get Challenge

This command directs the device to send challenge data to the host, which the host can then use to perform a specific sensitive operation / modify a specific type of device setting. Information about how the host should pass the required challenge data to the device is included in the documentation for all commands that use this security mechanism.

Upon providing the challenge to the host, the device sets an internal 5-minute countdown timer. When the time limit expires, the device will no longer accept the challenge. This binding of the command to a specific time period allows the device to detect and reject commands that have been captured/intercepted at one point in time and replayed later.

Table - Message Structure for Command 0x02::0x0B - Get Challenge

Tag

Len

Value(s) / Description

C0

01

01

Message Type Data Object (Tag C0) = 0x01 Command

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

0B

Command ID Data Object (Tag C2) = 0x0B Get Challenge

C4

02

Data Field Data Object (Tag C4 or E0) = Sub Operation:

0xDF71 = MSR Initial Key for DUKPT 0xDF73 = MSR Key Loader Certificate

0xDF75 = Device Authentication Request signed by MSR Key Loader Certificate 0xDF7B = Configuration signed by MSR Key Loader Certificate

0xDF7C = Manufacturer Command

If an error occurs, the device will terminate the command and report the error using an ACK Response containing the result code. For a full list of error codes, see 2.4.4 Result Code Data Object (Tag C3). If no error occurs, the device responds as follows:

Table - Response to Command 0x02::0x0B - Get Challenge

Tag

Len

Value(s) / Description

C0

01

02

Message Type Data Object (Tag C0) = 0x02 Response

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

0B

Command ID Data Object (Tag C2) = 0x0B Get Challenge

C3

01

00

Result Code Data Object (Tag C3) = 0x00 OK / Done

E0

Calculated

Data Field Data Object (Tag C4 or E0) = Bytes 0..1 Sub Operation:

0xDF71 = MSR Initial Key for DUKPT 0xDF73 = MSR Key Loader Certificate

0xDF75 = Device Authentication Request signed by MSR Key Loader Certificate 0xDF7B = Configuration signed by MSR Key Loader Certificate

0xDF7C = Manufacturer Command

Bytes 2..13 Data Block:

8 bytes device serial number 4 bytes random token

Command 0x02::0x0C - EPP Pairing Load KEK

This command is the second step in the EPP pairing process after Command 0x02::0x0A - EPP Pairing Certificate Exchange has completed successfully. This step loads a temporary key from the EPP that will be used during the third step of pairing (Command 0x02::0x0D - EPP Pairing Load Derivation Key). For details about the pairing flow, see Appendix G How to Pair With a Cryptera Encrypting PIN Pad.

Table - Message Structure for Command 0x02::0x0C - EPP Pairing Load KEK

Tag

Len

Value(s) / Description

C0

01

01

Message Type Data Object (Tag C0) = 0x01 Command

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

0B

Command ID Data Object (Tag C2) = 0x0C Load KEK

C4

Calculated

Data Field Data Object (Tag C4 or E0) =

Use complete response from the EPP GENERATE_KEK command when the response code is OK (first 4 bytes should be 00020000).

If an error occurs, the device will terminate the command and report the error using an ACK Response containing the result code. For a full list of error codes, see 2.4.4 Result Code Data Object (Tag C3). If no error occurs, the device responds as follows:

Table - Response to Command 0x02::0x0C - EPP Pairing Load KEK

Tag

Len

Value(s) / Description

C0

01

02

Message Type Data Object (Tag C0) = 0x02 Response

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

0B

Command ID Data Object (Tag C2) = 0x0C Load KEK

C3

01

00

Result Code Data Object (Tag C3) = 0x00 OK / Done

Command 0x02::0x0D - EPP Pairing Load Derivation Key

This command is used for the third and final step of the EPP pairing process. It securely loads a key shared with the paired EPP. This key is used to derive keys that protect the PIN and PAN sent to/from the EPP.. For details about the pairing flow, see Appendix G How to Pair With a Cryptera Encrypting PIN Pad.

Table - Message Structure for Command 0x02::0x0D - EPP Pairing Load Derivation Key

Tag

Len

Value(s) / Description

C0

01

01

Message Type Data Object (Tag C0) = 0x01 Command

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

0B

Command ID Data Object (Tag C2) = 0x0D Load Derivation Key

C4

Calculated

Data Field Data Object (Tag C4 or E0) =

EPP response to the FETCH_KEY(LINK_KGK) command if the response code was

OK starting with “B0080B0TX”

If an error occurs, the device will terminate the command and report the error using an ACK Response containing the result code. For a full list of error codes, see 2.4.4 Result Code Data Object (Tag C3). If no error occurs, the device responds as follows:

Table - Response to Command 0x02::0x0D - EPP Pairing Load Derivation Key

Tag

Len

Value(s) / Description

C0

01

02

Message Type Data Object (Tag C0) = 0x02 Response

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

0B

Command ID Data Object (Tag C2) = 0x0D Load Derivation Key

C3

01

00

Result Code Data Object (Tag C3) = 0x00 OK / Done

C4

03

3 byte EPP Key KCV. This should be compared with the KCV read from the EPP to confirm that the pairing process is complete and correct.

Command 0x02::0x0E - Get Key / Certificate Information

The host uses this command to get key or certificate information from the device.

Table - Message Structure for Command 0x02::0x0E - Get Key / Certificate Information

Tag

Len

Value(s) / Description

C0

01

01

Message Type Data Object (Tag C0) = 0x01 Command

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

0E

Command ID Data Object (Tag C2) = 0x0E Get Key / Certificate Information

C4

Calculated

Data Field Data Object (Tag C4 or E0) = Byte 0 Info ID from Table 4-49

If an error occurs, the device terminates the command and reports the error using an ACK Response containing the result code. For a full list of error codes, see 2.4.4 Result Code Data Object (Tag C3).

If no error occurs, the device responds by immediately sending two or more instances of Notification 0x01::0x10 - Big Block Device Data, which the host should concatenate, then interpret as follows:

Table - Response to Command 0x02::0x0E - Get Key / Certificate Information

Tag

Len

Value(s) / Description

C0

01

02

Message Type Data Object (Tag C0) = 0x02 Response

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

0E

Command ID Data Object (Tag C2) = 0x0E Get Key / Certificate Information

C3

01

00

Result Code Data Object (Tag C3) = 0x00 OK / Done

C4

Calculated

Data Field Data Object (Tag C4 or E0) = Byte 0 Info ID from Table 4-49

Byte 1 Key Status If Info ID < 0x80

0x00 = Empty (default) 0x01 = OK

0x02 = Exhausted If Info ID = 0x80:

0x00 to 0x05 = KCV type from Table 4-49

Byte 2 Data Length corresponding to the selected Info ID and shown in Table 4-49

Bytes 3.. Data corresponding to the selected Info ID, shown in Table 4-49

Table - Table of Info IDs and Data

Info ID

Key Status

Data Length

Data

Description

0x00

1

Label length

AMK (Acquirer Master Key) label

If AMK (Acquirer Master Key) exists

0x01,0x02

2

20

KSN

If no more keys

0x02

1

20

KSN

MSR key

0x04

1

calculated (<=59)

SN & subject’s

DN**

If MSR cert exists

0x07

1

Calculated (<=20)

KCV & EPP SN

length & EPP SN

Data and KCV for EPP Paired Key

0x80

kcv_type=1

4

KCV value

KCV for MSR key

0x80

kcv_type=2

4

KCV value

KCV for AMK (signed by MSR cert)

0x80

kcv_type=5

4

Hash value

Device Authentication Token signed by MSR Key Loader Certificate

*: lbllen = auth key’s label length

**: SN = serial number of cert

DN = distinguished names of subject or issuer of cert

Data length varies with SN and DN length; max length is 59

***: its corresponding CA cert

****: KCV = Key Check Value, where the lowest 6 digits are valid

Command 0x02::0x58 - Request Device Certificates

The host uses this command to request the Device Certificate, which the host would generally pass to Magensa web services that generate signed byte sequences for remote configuration commands.

Table - Message Structure for Command 0x02::0x58 - Request Device Certificates

Tag

Len

Value(s) / Description

C0

01

01

Message Type Data Object (Tag C0) = 0x01 Command

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

58

Command ID Data Object (Tag C2) = 0x58 Key Handling or Manufacturer Command

E0

02

Data Field Data Object (Tag C4 or E0) =

· 0xDF6E = Request Device Certificate, or

· 0xDF72 = Request Device Signing Certificate

If an error occurs, the device will terminate the command and report the error using an ACK Response containing the result code. For a full list of error codes, see 2.4.4 Result Code Data Object (Tag C3). If no error occurs, the device responds as follows:

Table - Response to Command 0x02::0x58 - Request Device Certificates

Tag

Len

Value(s) / Description

C0

01

02

Message Type Data Object (Tag C0) = 0x02 Response

C1

01

02

Application ID Data Object (Tag C1) = 0x02 Authentication Messages

C2

01

58

Command ID Data Object (Tag C2) = 0x58 Key Handling or Manufacturer Command

C3

01

00

Result Code Data Object (Tag C3) = 0x00 OK / Done

C4

Calculated

Data Field Data Object (Tag C4 or E0) =

X.509 Device certificate in DER format

The host should then wait (up to 90 seconds in some cases) for the device to respond synchronously with the requested data.

Last updated