HSM DS/3, DS/4 and DS/5 Principles - World Line · 2020. 7. 28. · Atos Worldline - Technology &...

Version: 04.03 Classification: Public

Haachtsesteenweg 1442 1130 Brussels Belgium

HSM DS/3, DS/4 and DS/5

Principles

HSM Documentation

Atos Worldline - Technology & Products / Engineering / HSM Page: 2/29 HSM DS/3, DS/4 and DS/5 Principles (04.03) Classification: Public

Version Management Report Version Name(s) Date Comments 01.00 F. Demaertelaere 28/06/2000 Initial version 01.01 F. Demaertelaere 08/08/2000 Integration of first remarks 02.00 F. Demaertelaere 12/01/2001 Final version 03.00 S. Yala Kabanzi 23/01/2003 DS4 added 03.01 P.Stienon 14/03/2006 Add of new disclaimer and some others

items 04.00 Anna Papayan 21/03/2011 Change the template into Atos

Worldline. 04.01 David Lheureux 01/10/2013 Make this document compatible with

DEP and ADYTON 04.02 David Lheureux 07/10/2013 DS5 added + change document name 04.03 David Lheureux 22/10/2013 Add the type of the Adyton Backup Key


CONFIDENTIALITY

The information in this document is confidential and shall not be disclosed to any third party in whole or in part without the prior written consent of Atos Worldline S.A./N.V.

COPYRIGHT

The information in this document is subject to change without notice and shall not be construed as a commitment by Atos Worldline S.A./N.V. The content of this document, including but not limited to trademarks, designs, logos, text, images, is the property of Atos Worldline S.A/N.V. and is protected by the Belgian Act of 30.06.1994 related to author’s right and by the other applicable Acts.

The contents of this document must not be reproduced in any form whatsoever, by or on behalf of third parties, without the prior written consent of Atos Worldline S.A./N.V. Except with respect to the limited license to download and print certain material from this document for non-commercial and personal use only, nothing contained in this document shall grant any license or right to use any of Atos Worldline S.A./N.V.’s proprietary material.

LEGAL DISCLAIMER

While Atos Worldline S.A./N.V. has made every attempt to ensure that the information contained in this document is correct, Atos Worldline S.A./N.V. does not provide any legal or commercial warranty on the document that is described in this specification. The technology is thus provided “as is” without warranties of any kind, expressed or implied, included those of merchantability and fitness for a particular purpose. Atos Worldline S.A./N.V. does not warrant or assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product or process disclosed. To the fullest extent permitted under applicable law, neither Atos Worldline S.A./N.V. nor its affiliates, directors, employees and agents shall be liable to any party for any damages that might result from the use of the technology as described in this document (including without limitation direct, indirect, incidental, special, consequential and punitive damages, lost profits).

JURISDICTION AND APPLICABLE LAW

These terms shall be governed by and construed in accordance with the laws of Belgium. You irrevocably consent to the jurisdiction of the courts located in Brussels for any action arising from or related to the use of this document.

sa Atos Wor ld l ine nv – Chaussée de Haech t 1442 Haachtses teenweg B-1130 Bruxe l les -Brusse l - Be lg i um

RPM-RPR Bruxe l les -Brusse l - TVA-BT W BE 0418 .547 .872


TABLE OF CONTENTS

TABLE OF CONTENTS ......................................................................................... 4

1. SCOPE OF THE DOCUMENT ....................................................................... 5

1.1. REFERENCES ................................................................................................ 5

1.2. CONTACTING ATOS WORLDLINE ............................................................. 5

2. DS3 .................................................................................................................... 6

2.1. INTRODUCTION TO DS3 ................................................................................ 6

2.1.1. Principles ............................................................................................ 6

2.1.2. Flexibility ............................................................................................ 6

2.1.3. Optimisation of Message Size .............................................................. 6

2.2. DS3 COMMAND STRUCTURE ........................................................................ 6 2.2.1. DS3 Command Message ...................................................................... 6

2.2.2. DS3 Reply Message ............................................................................. 7

2.2.3. Example .............................................................................................. 9

2.3. DS/3 PHILOSOPHY ....................................................................................... 9

2.3.1. Tag Principles ..................................................................................... 9

2.3.2. Command Processing ........................................................................ 14

3. DS4 .................................................................................................................. 22

3.1. INTRODUCTION TO DS4 .............................................................................. 22

3.1.1. Principle ........................................................................................... 22

3.1.2. Input Data ......................................................................................... 22

3.1.3. Output data ....................................................................................... 22

3.1.4. Command message ............................................................................ 22

3.2. DS4 COMMAND STRUCTURE ...................................................................... 23 3.2.1. DS4 Command Message .................................................................... 23

3.2.2. DS4 Reply Message ........................................................................... 24

4. DS3 VERSUS DS4: DIFFERENCES AND SIMILARITIES ....................... 26

4.1. TAG ........................................................................................................... 26 4.1.1. DS4 Command tag ............................................................................ 26

4.1.2. Other tags ......................................................................................... 26

4.2. COMMAND MESSAGE AND REPLY MESSAGE ............................................... 26

5. DS5 .................................................................................................................. 28

6. COMMAND PROCESSING .......................................................................... 29

6.1. PRELIMINARY REMARKS ............................................................................ 29 6.2. INPUT DATA .............................................................................................. 29

6.3. COMMAND EXECUTION .............................................................................. 29

6.4. DATA OUTPUT ........................................................................................... 29


1. SCOPE OF THE DOCUMENT

The DEP and the ADYTON support three ways to access dedicated functionality (and its keys) in a secure way: the DEP System 3, the DEP System 4 and the DEP System 5.

• With the DS3, dedicated functions could easily be chained to each other to build new functionality in a flexible way.

• With the DS4/DS5, this flexibility is drastically reduced for the benefit of a

reduction of the time spent in the parsing of the message sent to the HSM. This document explains in the principles of DS3, DS4 and dS5. In this document, the term HSM is used for both DEP and ADYTON.

1.1. REFERENCES

This document contains a reference to other documents about the HSM. This paragraph gives a list of all the documents referred to.

• DEP/NMS User Manual • ADYTON Reference Guide

There are no references made to the following documents, but they could be useful to understand this document.

• DEP Introduction to DEP • DEP General Architecture • DEP Glossary

1.2. CONTACTING ATOS WORLDLINE

You can visit Atos Worldline on the World Wide Web to find out about new products and about various other fields of interest. URL : www.atosworldline.com. For the documentation visit http://www.banksys.com web page. For support on issues related to HSM, customers, partners, resellers, and distributors can send an email to the DEP Hotline: mailto:[email protected].


2. DS3

2.1. INTRODUCTION TO DS3

2.1.1. Principles

The main principle of the DEP System 3 (DS3) philosophy is the splitting of an overall functionality to be executed by the HSM into several elementary commands, each having a dedicated function in the HSM. These elementary commands can be chained together to obtain a command sent to the HSM in only one call. The advantages of this system are flexibility and optimisation of message sizes.

2.1.2. Flexibility

Certain small modifications in the external commands addressed to the HSM can be done without modifying the Application Software and extra elementary commands can be placed in the command to obtain the desired operation. So it is possible to execute complicated operations using only one call to the HSM. Moreover, it is not necessary anymore to make a complete copy of an existing command and to slightly modify it in order to create a new command nearly similar to the first one. The adaptation/creation of a simple subcommand is enough! The integrator has thus the complete flexibility to chain different dedicated functionality of the HSM in one message.

2.1.3. Optimisation of Message Size

Only the data really needed is input and output. In addition, in a command it can be requested to execute the same elementary command more than once. This means that a part of the data fields can be common, and have to be sent only once.

2.2. DS3 COMMAND STRUCTURE

2.2.1. DS3 Command Message

2.2.1.1. DS3 Structure Description

Every DS3 Command Message sent is built up in four blocks: a start indicator, input data fields, a list of elementary commands and a list of output data fields. The structure of the DS3 Command Message is described in detail below. DS3 Command Message Start of command 0xFF

One byte identifying the DS3 format of the Command Message. Input Data Fields dataTAG in(1) valuein(1) dataTAGin(2) valuein(2) … dataTAGin(n)

valuein(n) List of data fields (with their values) needed to execute the subcommands (list may be empty). The sequence of the different TAGs is not important.


Elementary commands interfaceTAG(1) interfaceTAG(2) interfaceTAG(3) … interfaceTAG(m)

List of elementary commands to be performed using the input data. The elementary commands will be executed in the same order as they appear in the command.

Output Data Fields dataTAGout(1) dataTAGout(2) dataTAGout(3) … dataTAGout(k) List of data fields that will be returned by the HSM in the Reply Message (list may be empty). The sequence of the different TAGs does not influence the sequence of their values.

The values of the Input Data Fields, Elementary Commands and Output Data Fields may be found in the appropriate specifications of the Application Software running on the HSM.

2.2.1.2. Example

This paragraph contains a simple example of a DS3 Command Message.

2.2.2. DS3 Reply Message


The structure of the Reply Message of the HSM depends on the outcome of the treatment of the Command Message by the HSM, i.e. is different when an error is detected or when everything went correctly.

Start of command

FF

01130100 E3AAC957359DD18D5F938201130500 FF01000000 EB1FA0115B0F5B2E5D1901FBD04AB0DB24B45F01130200 749B075EECE0D1A901100000 100203E35B124EEB4E4801130300 C1F9D975590D68CB

021000000213010002000000

01000500

Input Data Fields

Output Data Field

ElementaryCommands

(BKS_DEC_BAPOF,BEST_DEC_PIN, VER_PIN)


2.2.2.1.1. Correct Execution

In case of correct execution of the Command Message, the DS3 reply of the HSM will have the following structure: DS3 Reply Message Reply Code 0x00

One byte indicating that no error occurred.

Output Data Fields dataTAGout(1) valueout(1) dataTAGout(2) valueout(2) … dataTAGout(k) valueout(k) List of data fields with their values returned by the HSM and specifically requested in the DS3 Command Message (see paragraph 2.2.1.1 on page 6). The sequence of the different TAGs is not important.

2.2.2.1.2. Error Case

When an error occurs during command execution, the DS3 Reply Message contains information about the error. DS3 Reply Message Reply Code •••• 0xF0: blocking internal HSM error (HSM should be put out of service)

•••• 0xF1: no blocking internal HSM error (do not use this command again with this HSM and give the error code to the Security Officer).

•••• 0xF2: error in Command Message due to field missing, field out of range, … (error in host application).

•••• 0xFE: error generated by the HSM boot software (not relevant for ADYTON)

•••• 0xFF: normal HSM error to be treated by the host application (e.g. PIN verification failed).

One byte identifying the error type.

Field Identifier dataTAG or interfaceTAG TAG of the Input Data Field or Elementary Command causing the error. When the error was caused by a dataTAG, there was no Elementary Command executed yet.

Error Identifier errorTAG Identification of the error.

Additional Information <free format> The presence of this area depends on the error code. This additional information on an error could be the TAG of the key not loaded, …

The values of the Error Identifiers and Additional Information may be found in the appropriate specifications of the Software running on the HSM.


2.2.3. Example

This paragraph contains an example of the DS3 Reply Message when no error occurs and when a problem is detected by the HSM (missing key).

2.3. DS/3 PHILOSOPHY 2.3.1. Tag Principles

The DS3 philosophy is based on tags. A tag is a four-byte identifier that is structured in the following way:

• Type Identifier (1 byte) • Library Identifier (1 byte) • Sequence Number within the Library (1 byte) • Special Identifier (1 byte)

Different types of tags are defined in the HSM System. Every type has another purpose. The use of the special identifier depends on the type of the tag. Remark that all the tags are library dependent. A tag is defined in a certain library. Separate sequence numbers are managed within every library.

2.3.1.1. Types of tags

As already mentioned above, different types of tags do exist. Every type of tag has its own type identifier.

• 0x01: data tag • 0x02: elementary command tag • 0x03: error tag • 0x04: key tag (not relevant for ADYTON) • 0x05: capability tag (not relevant for ADYTON) • 0x06: counter tag (not relevant for ADYTON)

Reply Code

00

01000500 00

Output Data Field(TAG)

F1

02000000

03000500

04100100

Reply Code

Field Identifier(InterfaceTAG =

VER_PIN)

Error Identifier(ErrorTAG =Missing Key)

AdditionalInformation

(BAPOF_KEY)

no e

rror

erro

r

Output Data Field(Value)


• 0x07: parameter tag (not relevant for ADYTON) • 0x12 elementary DS/4 command tag (see paragraph DS4 on page 22)

2.3.1.1.1.Data Tag

A data tag is used to identify the data information that is delivered to the HSM in a Command Message (see ‘Input Data Fields’ in paragraph 2.2.1.1 on page 6). The same tag type is used to identify the information that should be returned by the HSM. These tags are listed in the Command Message (see ‘Output Data Fields’ in paragraph 2.2.1.1 on page 6) and re-appear in the HSM Reply Message together with its value (see ‘Output Data Fields’ in paragraph 2.2.2.1 on page 7). The HSM knows the data tags. Every data tag has some dedicated internal properties:

• identification of verification and validation procedures • indication whether the data has a fixed length (and definition of its length)

or a variable length • indication whether more than one instance is supported or not • input/output restrictions when required (certain data may not be input

and/or output) • identification of the first possible instance

The same data type can be delivered more than once in one Command Message.

2.3.1.1.2. Elementary Command Tag

An elementary command tag identifies the elementary command that should be executed by the HSM on some dedicated input data. The input data could be externally delivered in a host command or generated internally (depending on the input/output restrictions of the data). The elementary commands are delivered in the HSM Command Message (see ‘Elementary Commands’ in paragraph 2.2.1.1 on page 6). The HSM knows the elementary command tags. Every subcommand tag has some dedicated internal properties:

• the capability that is required to execute the subcommand (only for DEP) • a counter indicating how many times the subcommand is executed (only for

DEP) Before the elementary commands are executed, the data is first validated.

2.3.1.1.3. Error Tag

An error tag identifies the type of error that occurred. They are only returned when the HSM detects a problem while executing a Command Message. The HSM knows the error tags. Every error tag has some dedicated internal properties:


• a counter indicating how many times the error has appeared (only for DEP) • the identification of the reply code (see ‘Reply Code’ in paragraph 2.2.2.1

on page 7) • the length of the additional information returned in the HSM Reply

Message (see ‘Additional Information’ in paragraph 2.2.2.1 on page 7)

2.3.1.1.4. Key Tag (only for DEP)

A key tag identifies a key in the DEP Crypto Module. The DEP Crypto Module knows the key tags. Every key tag has some dedicated internal properties:

• indication whether more than one instance is supported or not • indication whether the key is read-only (cannot be deleted or modified) or

not • the type of the key (DES, RSA, AES, ECC) • the length of the key • identification of the procedure to start after key introduction (e.g.

derivation, deleting other keys, …) The special field permits to use different key values for the same type of key (instances).

2.3.1.1.5. Key Identifier (only for ADYTON)

In the ADYTON, the keys are identified by a key identifiers (= Key Usage + Key Name) which are more flexible than Key tags. To keep the compatibility between ADYTON and DEP, the Key Name defined in the ADYTON should correspond to the key instance defined in the DEP Crypto Module.

2.3.1.1.6. Capability Tag (not relevant for ADYTON)

A capability tag identifies a right to perform certain operations in the DEP Crypto Module. The DEP Crypto Module knows the capability tags. Every capability tag has some dedicated internal properties:

• name of the capability • counter indication how many times or how long the capability is allowed to

exist

2.3.1.1.7. Counter Tag (not relevant for ADYTON)

The DEP Crypto Module counts how many times an elementary command was executed and how many times an error occurred. These counters are identified with a counter tag.

Atos Worldline - Technology & Products / Engineering / HSM Page: 12/29 HSM DS/3, DS/4 and DS/5 Principles (04.03) Classification: Public The DEP Crypto Module knows the counter tags. Every counter tag has some dedicated internal properties:

• name of the counter • value of the counter

Remark that all the counters could be consulted by using the DEP/NMS application (see DEP/NMS User Manual for more information).

2.3.1.1.8. Parameter Tag (not relevant for ADYTON)

The use of parameters is introduced to configure the Application Software. A parameter tag identifies the parameter in the DEP Crypto Module. The DEP Crypto Module knows the parameter tags. Every parameter tag has some dedicated internal properties:

• lowest and highest instance limit • type of parameter (byte, word, double word, digit, string, …) • format of the parameter (decimal, hexadecimal) • group name to which the parameter belongs • parameter name • unit of the parameter • maximal and minimal value/length of the parameter

The DEP Crypto Module foresees instance support. Remark that all the parameters could be consulted by using the DEP/NMS application (refer to the DEP/NMS User Manual for more information).

2.3.1.2. Standard Tags

Every Application Software contains some standard tags, defined in the HSM Standard Library. This paragraph gives an overview and explanation of the most important tags, especially the tags required for making a HSM operational. Remark that only the tags for keys, capabilities and parameters are explained. Refer to the dedicated specifications of the Software running on the HSM for more information about the tags.

2.3.1.2.1. Keys

This paragraph gives an overview of the standard keys supported in every HSM.

TAG/USAGE DESCRIPTION 04 00 00 00 (DES) 04 00 10 00 (AES) DEP_DMK_DES DEP_DMK_AES_256

(DEP Master Key) All the Application Keys in the memory of the HSM can be stored outside the HSM (key backup). For security reasons the keys can only leave the HSM in a protected way. Therefore, they are all encrypted (together with their tag) under the DMK. When the backup/restore functionality of the HSM is not used, it is not required to load the DMK. The DMK is only used in the ADYTON to


restore DEP’s backups. ADYTON_BACKUP_KEY(ABK) – AES 256 bits

(ADYTON Backup Key) All the Application Keys in the memory of the ADYTON can be stored outside the ADYTON (key backup). For security reasons the keys can only leave the ADYTON in a protected way. Therefore, they are all encrypted (together with their internal properties) under the ABK.

2.3.1.2.2. Parameters (not relevant for ADYTON)

This paragraph gives an overview of the standard parameters supported in every DEP Crypto Module.

TAG DESCRIPTION 07 00 00 00 (KEYMAC Slice ) The integrity of the keys in the DEP Crypto Module is

continuously verified by recalculating the KEYMAC (compared with the reference KEYMAC). The KEYMAC is recalculated in slices, meaning that on every host call an intermediate KEYMAC is upgraded by taking into account one or more additional keys. When all keys are taken into the intermediate KEYMAC, it is compared with the reference KEYMAC. The KEYMAC Slice parameter defines the number of keys that are integrated into the intermediate KEYMAC every time it is upgraded (default value is one). The higher the KEYMAC Slice, the faster the integrity of the keys is checked, but the slower the DEP Crypto Module replies on a host command. When the KEYMAC Slice is higher than the total number of keys available in the DEP Crypto Module, the integrity of all the keys is checked during every host command. When the KEYMAC Slice is set to zero, the integrity of the keys is no longer verified.

2.3.1.2.3. Capabilities (not relevant for ADYTON)

This paragraph gives an overview of some standard capabilities supported in every DEP Crypto Module.


TAG DESCRIPTION 05 00 00 00 (CAP_STD_SAVE_KEYS) Capability that gives the right to perform backup and

restore operations of the application keys. 05 00 03 00 (CAP_STD_SW_LOAD) CAP_STD_SW_LOAD should be available in the DEP

Crypto Module before new Application Software can be loaded (Load Application) or before a running Application Software can be ended (End Application).

05 00 05 00 (CAP_STD_TRACE) Traces at DEP/NT DEP Handler level and DEP/NT Host Interface level are only allowed when the CAP_STD_TRACE is loaded. When the capability is not loaded, empty traces are generated.

05 00 07 xx (CAP_STD_SET_PARAMETER) The CAP_STD_SET_PARAMETER gives the right to modify the value of a parameter. Parameters are organised in groups and the last (special) byte of the CAP_STD_SET_PARAMETER tag (xx) defines the group of parameters that might be changed. All the parameters available in a dedicated library belong to the same group and the library identification identifies the group. When the special byte (xx) equals zero, the operator has the right to modify all the parameters in all the groups.

2.3.2. Command Processing

2.3.2.1. Preliminary Remark

For security reasons, the HSM does not keep information between different Command Messages sent by the host. When different functions should be executed on some data, all the function/elementary commands identifications should be delivered in one HSM call. Otherwise, intermediate information output by the HSM should be re-delivered in the following Command Message.

2.3.2.2. Input Data

After receiving a command, the HSM first verifies the format and the value of each input data field separately. All the information about the different data fields can be found in the appropriate specification document of the running Software. It is possible to place a restriction on a data. Typical data restriction is:

• range restriction (only some values are allowed) • input restriction (the value of the data can only be computed by the HSM

internally and not input) • output restriction (the data is secret and thus may not leave the HSM) • one instance only (only one data instance can be generated or input)

When an error occurs, the HSM immediately stops the processing of the command, makes the data from the host in its memory unusable and returns an error message. When no error occurs, all the data are stored in the HSM’s memory in order to be used by the elementary commands.


2.3.2.3. Elementary Command Execution

According to the elementary command (also called interface) definition, some data are needed for the correct execution of the elementary command. The elementary command will use the data it will found in the HSM’s memory and will create one or more new data and/or modify one or more existing ones. When the elementary command creates a new data, it can be used by the next elementary commands of the command. For example, the elementary command "Create derived key" can pass a data (derived key) to the elementary command "Generate MAC". Thus, the origin of the instances of a data, present at a given time in the HSM’s memory, can be

• sent by the host (the data given in input of the Command Message) • created by a previous elementary command (added to the list of instances

already existing) • modified by a previous elementary command.

The HSM executes the elementary commands in the same order as they appear in the command. We assume that all operations performed by previous elementary commands on the data list are executed correctly. Therefore, checks performed on data at input are not repeated at elementary command level. For each elementary command the HSM however checks whether the needed data is internally present and whether the elementary command restrictions are respected. When an error occurs, the HSM stops immediately the command processing, makes the data instances unusable and returns an error message.

2.3.2.4. Data Output

After processing the elementary commands, the HSM constructs the Reply Message with all data fields asked by the user. When building this message, the HSM verifies whether the data fields asked in output can be given following the restriction (thus the fields must have no output restriction). When an error occurs, the HSM stops immediately the command processing, makes the data instances unusable and returns an error message. When everything is going fine, the Reply Message is sent to the host and the data instances in the HSM’s memory are made unusable in order to accept the next Command Message.


2.3.2.5. Example

The following example is rather basic and verifies the PIN entered by a cardholder. After the PIN introduction it is by one or other means encrypted using the BEST protocol (BEST Encrypted PIN). The reference PIN is available on the host in encrypted format (BKS BAPOF).

When the HSM received the Command Message, it decrypts (02100000) first the BKS BAPOF to retrieve the Reference PIN (internal data 01000700). Therefore the BKS BAPOF (01100000) and BKS ISO2 Track (01000000) are required. In the next step, the Customer PIN (internal data 01000600) is obtained by decrypting (02130100) the BEST Encrypted Key. This requires the BEST Zone PIN Working Key (01130100), the BEST Encrypted Key (01130300) and the BEST Encrypted PIN (01130200). For simplification, the tag 01130500 (required for BEST) is not explained. Now the Reference PIN (01000700) and the Customer PIN (01000600) are available in the internal memory of the HSM. Both data are restricted as ‘unallowed input/output’. Although for the verification (02000000) of both PINs, the HSM compares both values. The result is stored in the Result PIN Verification variable (01000500), which is returned on demand to the host.

2.3.2.6. Special Cases

This paragraph explains some special cases when using the DS3 philosophy of the HSM.

FF

01130100 E3AAC957359DD18D5F938201130500 FF01000000 EB1FA0115B0F5B2E5D1901FBD04AB0DB24B45F01130200 749B075EECE0D1A901100000 100203E35B124EEB4E4801130300 C1F9D975590D68CB

021000000213010002000000

01000500

Start of commandBEST Zone PIN

Working Key

BEST EncryptedPIN

BEST EncryptedKey

BKS BAPOF (BKSEncrypted PIN)

BKS ISO2 Track

BEST Decrypt PIN(=Customer PIN)

BKS DecryptBAPOF (=Reference

PIN)

Verify PIN (compareReference PIN and

Customer PIN)

Result PINVerification


2.3.2.6.1. Same Elementary Command Requested Several Times

One elementary command can be executed more than once in one Command Message. Imagine that the elementary command F needs y instances of the same data type A (often y will be equal to one) and is executed x times. Now, let’s consider the different possibilities to create the Command Message. 1. the data A is present y times

The Y instances of the data A will be re-used for each instance of the elementary command, i.e. F1 uses A1, A2, … Ay; F2 uses A1, A2, … Ay; …; Fx uses A1, A2, …, Ay. 2. the data A is present xy times

The first instance of the elementary command F will use the y first instances of the data A and the i th (1 ≤ i ≤ x ) instance of the elementary command will use the data instances from (i-1)y+1 to iy, i.e. F1 uses A1

1, A21, … Ay

1; F2 uses A12, A2

2, … Ay2; …;

Fx uses A1x, A2

x, …, Ayx.

3. the data A is present more than xy times

A1 AyA3 ...A2 F1 FxF3 ...

F2

A11 Ay

1A31

...A2

1 F1 FxF3 ...F2

A12 Ay

2A32

...A2

2

...

A1x Ay

xA3x

...A2

x

A13 Ay

3A33

...A2

3


Only the xy first instances of the data A will be used and the other instances are ignored, i.e. F1 uses A1

1, A21, … Ay

1; F2 uses A12, A2

2, … Ay2; …; Fx uses A1

x, A2x, …,

Ayx.

4. data A is present less then y times

When there are not enough data instances of A available (e.g. y-1 instances), an error is returned.

A11 Ay

1A31

...A2

1 F1 FxF3 ...F2

A12 Ay

2A32

...A2

2

...

A1x Ay

xA3x

...A2

x

A13 Ay

3A33

...A2

3

A1x+1 A3

x+1A2x+1

A1 Ay-1A3 ...A2 F1 FxF3 ...

F2

Atos Worldline - Technology & Products / Engineering / HSM Page: 19/29 HSM DS/3, DS/4 and DS/5 Principles (04.03) Classification: Public 5. the data A is present more than y times but less than xy times

When there are not enough data instances of A available (e.g. xy-1 instances), an error is returned.

2.3.2.6.2. Same Data Output Several Times

The normal rules for output data are the same as for input data. Imagine that the data output list requests y instances of the same data type B and that there are x data instances present. Now, let’s consider the different possibilities to create the Command Message. 1. the data B is present y times (x=y)

When the data B is present in the HSM as much as requested in the data output list, all the requested instances shall be output. 2. the data B is present less than y times (x<y)

A11 Ay

1A31

...A2

1 F1 FxF3 ...F2

A12 Ay

2A32

...A2

2

...

A1x Ay-1

xA3x

...A2

x

A13 Ay

3A33

...A2

3

B1 BxB3 ...B2

B1 BxB3 ...B2

DE

P/N

TM

emo

ry

B1 BxB3 ...B2

B1 BxB3 ...B2

DE

P/N

TM

emo

ry

...By

Atos Worldline - Technology & Products / Engineering / HSM Page: 20/29 HSM DS/3, DS/4 and DS/5 Principles (04.03) Classification: Public When there are more data instances requested as there are present in the HSM, the first x requests are taken into consideration. The remaining (y-x) requests are ignored. This means that data (including their tags) asked in the output list will not be output if not present. 3. the data B is present more then y times (x>y)

In the case that there are more data instances of B available in the HSM as requested in the data output list, only the first y data instances shall be output.

2.3.2.6.3. Data in the Input List present in the Output List

All elementary commands can generate new information that has to be stored in the memory of the HSM. The DS3 philosophy defines some rules when a new data instance is created or when an existing one is modified. When an elementary command has a certain data type as input and has the same data type as output, the input data instance is modified with new information. Exceptionally, it is possible that new instance of the data is created instead of being modified, but then it is specified in the dedicated software documentation as a remark concerning that data in the Output Data List (mention: a new instance of the data is created).

2.3.2.6.4. One Instance Only

When a data has a one instance only property, every elementary command that requires this data shall deal with the first data instance, even when different instances of the data are given on the input. When the elementary command has the one instance only data as output, the first data instance shall be modified.

2.3.2.7. General Examples

1. elementary command F needs one instance of a data A A1 F1 � F1 uses A1 A1 A2 F1 � F1 uses A1 A1 F1 F2 � both F1 and F2 use A1 A1 A2 F1 F2 � F1 uses A1 and F2 uses A2 A1 A2 F1 F2 F3 � gives an error 2. elementary commands F and G need one instance of a data A

B1 ByB3 ...B2

B1 ByB3 ...B2

DE

P/N

TM

emo

ry

...Bx

Atos Worldline - Technology & Products / Engineering / HSM Page: 21/29 HSM DS/3, DS/4 and DS/5 Principles (04.03) Classification: Public A1 F1 G1 � both F1 and G1 use A1 A1 A2 F1 G1 � both F1 and G1 use A1 A1 F1 F2 G1 � F1 uses A1, F2 uses A1 and G1 uses A1 3. elementary command F needs two instances of a data A A1 A2 F1 � F1 uses A1 and A2 A1 A2 F1 F2 � both F1 and F2 use A1 and A2 A1 A2 A3 A4 F1 F2 � F1 uses A1 and A2 and F2 uses A3 and A4 A1 A2 A3 F1 F2 � gives an error 4. elementary command F needs data A, modifies it, and creates a next instance of A; elementary command G needs two instances of A A1 F1 G1 � F1 uses A1, modifies it to A1' and generates A2; G1 uses A1'

and A2 A1 F1 F2 G1 � F1 uses A1, modifies it to A1' and generates A2; F2 uses A2,

modifies it to A2' and generates A3; G1 uses A1' and A2’


3. DS4

3.1. INTRODUCTION TO DS4

3.1.1. Principle

The DEP System 4 (DS4) is designed to reduce the part of the command processing time spent on the parsing of DS3 calls to retrieve input data. The problem of parsing data may particularly be emphasized when several DS3 elementary commands are chained in one HSM call (see for example paragraph 2.3.2.5 on page 16). For that purpose, some modifications are introduced compared to DS3. These modifications are about the concept of data input in a command, the concept of data output by a command and the concept of Command Message. They are explained in the following sections.

3.1.2. Input Data

The input data of a DS4 command may be empty or have one or several fields. For a given command:

• the number of fields is fixed and cannot be changed; • the sequence of the fields within the input data is fixed and cannot be

changed; • The length of each field is also fixed, except for variable length fields, for

which another field in the input data is used to indicate to the command the effective length.

The major consequence of the static layout of the input data is the useless of tags for the identification of the input data fields. Hence, in contrast to the DS3, tags will not be used to identify data fields in the DS4.

3.1.3. Output data

The output data of a DS4 command may be empty or have one or several fields. The length of each field is fixed, except for variable length fields, for which another field in the output data is used to indicate the effective length. For a given command, the number of fields is fixed, and cannot be changed. Once again, the static layout of the output data makes useless the use of tags to identify the output data fields. Hence, in contrast to the DS3, tags will not be used to identify output data fields in the DS4.

3.1.4. Command message

A DS4 Command Message is made of only one DS4 command with the required input data fields in the fixed sequence and with the fixed length. The DS3 command

Atos Worldline - Technology & Products / Engineering / HSM Page: 23/29 HSM DS/3, DS/4 and DS/5 Principles (04.03) Classification: Public chaining propriety is thus not supported in DS4. The layout of DS4 Command Message is explained in the next section.

3.2. DS4 COMMAND STRUCTURE

3.2.1. DS4 Command Message


Every DS4 Command Message sent is built up in three blocks: a start indicator, the identifier of the DS4 command (also named command tag) and a list of input data fields. This list may be empty. DS4 Command Message Start of command 0xFF

One byte used to identify the DS3 or the DS4 format of the Command Message.

Command 0x12…… DS4 command identifier. The identifier is 4 bytes long and starts with the byte 0x12.

Input Data Fields String of bytes. Data fields needed by the DS4 command. The sequence of fields is important. This block may be empty.

3.2.1.2. Example

This paragraph contains a simple example of a DS4 Command Message

Start of command

FF12310200

10E3AAC957359DD18D5F938215FAB8964D00EB1FA0115B0F5B2E000000000000000001

Input Data Fields

command


3.2.2. DS4 Reply Message


The structure of the reply of the message of the HSM depends on the outcome of the treatment of the Command Message by the HSM, i.e. is different when an error is detected or when everything went correctly.

3.2.2.1.1.Correct execution

In case of correct execution of the Command Message, the DS4 reply of the HSM will have the following structure: DS4 Reply Message Reply Code 0x00

One byte indicating that no error occurred.

Output Data Fields String of bytes returned by the HSM as result of the command processing. This block may be empty

3.2.2.1.2.Error Case

When an error occurs during the command execution, the DS4 Reply Message contains information about the error.

Atos Worldline - Technology & Products / Engineering / HSM Page: 25/29 HSM DS/3, DS/4 and DS/5 Principles (04.03) Classification: Public DS4 Reply Message Reply Code •••• 0xF0: blocking internal HSM error (HSM should be put out of service)

•••• 0xF1: no blocking internal HSM error (do not use this command again with this HSM and give the error code to the Security Officer).

•••• 0xF2: error in Command Message due to field missing, field out of range, … (error in host application).

•••• 0xFE: error generated by the DEP boot software. (not relevant for ADYTON)

•••• 0xFF: normal DEP error to be treated by the host application (e.g. PIN verification failed).

One byte identifying the error type.

Field Identifier interfaceTAG TAG of the command causing the error.

Error Identifier errorTAG Identification of the error.

Additional Information <free format> The presence of this area depends on the error code. This additional information on an error could be the TAG of the key not loaded, …

3.2.2.2. Example

This paragraph contains an example of the DS4 Reply Message when no error occurs and when a problem is detected by the HSM.

Reply Code

00

1810A01F87E62102ABC841657851A36DE601879863EA5BFF8A

Output Data Field

F1

12310200

03000500

04310100

Reply Code

Field Identifier(InterfaceTAG)

Error Identifier(ErrorTAG =

Missing Key)

AdditionalInformation (Tag

of the KEY)

no e

rror

erro

r


4. DS3 VERSUS DS4: DIFFERENCES AND SIMILARITIES

4.1. TAG

DS4 is also tag-based, and thus the principle of tags explained in paragraph 2.3.1 on page 9 fully applies here except that:

•••• the tag of a DS4 command is different from the tag of a DS3 command •••• in DS4, data do not have tags, whereas in DS3 they do

The types of tags are summarized below:

•••• 0x12: DS4 command tag (this is the only type of tag specific to DS4) •••• 0x03: error tag •••• 0x04: key tag •••• 0x05: capability tag (not relevant for ADYTON) •••• 0x06: counter tag (not relevant for ADYTON) •••• 0x07: parameter tag (not relevant for ADYTON)

4.1.1. DS4 Command tag

A DS4 command tag identifies the command that should be executed by the HSM on the input data. The input data is externally delivered in a Command Message. The command is delivered in the Command Message (see paragraph 3.2.1.1 on page 23). The HSM knows the command tags. Every command tag has some dedicated internal proprieties:

•••• the capability that is required to execute the command (not relevant for

ADYTON) •••• the identification of keys to use in the command (not relevant for

ADYTON) •••• a counter indicating how many times the command is executed (not relevant

for ADYTON) Before the command is executed, the input data fields are first validated.

4.1.2. Other tags

The concept of other tags (error tag, key tag, capability tag, counter tag, parameter tag) remains the same as in DS3. They are explained in the paragraph 2.3.1 on page 9.

4.2. COMMAND MESSAGE AND REPLY MESSAGE

For the persons programming the applications that send messages to the HSM and that receive the reply from the HSM (Host Programming), the most significant difference

Atos Worldline - Technology & Products / Engineering / HSM Page: 27/29 HSM DS/3, DS/4 and DS/5 Principles (04.03) Classification: Public between DS4 and DS3 is the structure of their respective Command Messages and the Reply Messages. The structure of the DS4 (respectively DS3) Command Message and Reply Message is explained in the paragraph 3.2 on page 23 (respectively. in the paragraph 2.2 on page 6).


5. DS5

DS5 is a performance optimized command structure for ADYTON, based on a LENGTH-VALUE (LV) sequence. The order of the fields is fixed and specified in every DS5 command. The LENGTH fields are coded on 4 bytes (hexadecimal) with the most significant byte first (MSB).

To get more information about DS5, refer to the specific documentation the software which is loaded on the HSM.


6. COMMAND PROCESSING

6.1. PRELIMINARY REMARKS

For security reasons, the HSM does not keep information between the different Command Messages sent by the host. After the processing of a command, all the data sent by the host and those possibly generated by the HSM are cleared from the HSM’s internal memory.

6.2. INPUT DATA

After receiving a command, the HSM first verifies the format and the value of each input data fields separately. All the information about the different data fields can be found in the appropriate specification document of the Application Software. A range restriction may apply on a data field (only some values are allowed). When an error occurs (e.g. a data field is badly formatted, a data field is out of range or a data field is missing), the HSM immediately stops the processing of the command, and returns an error message. When no error occurs, the HSM continues with the command processing.

6.3. COMMAND EXECUTION

The HSM executes the command according to the command definition. During this execution, the HSM verifies that all the keys and capabilities needed by the command are active. When an application dependent error occurs (e.g. keys or capabilities not active, or one of the error cases described in the command definition), the HSM stops immediately the command processing and returns the appropriate error message.

6.4. DATA OUTPUT

After processing the command, the HSM constructs the Reply Message with the data fields corresponding to the command processed.

Date post:	16-Oct-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

HSM DS/3, DS/4 and DS/5 Principles - World Line · 2020. 7. 28. · Atos Worldline - Technology &...

Documents