Introduction To DEP

Haachtsesteenweg 1442
1130 Brussels
Belgium
DEP Documentation
Introduction to DEP
Version: 04.00 Classification: Public

Atos Worldline - Technology & Products / Engineering / DEP Page: 2/35
Introduction to DEP (04.00) Classification: Public
Version Management Report

Version Name(s) Date Comments
01.00 TheSteamFactory 02/05/2000 First draft
01.01 TheSteamFactory 05/06/2000 Second draft
01.02 TheSteamFactory 13/06/2000 Final draft
01.03 TheSteamFactory 04/07/2000 Final
01.04 F. Demaertelaere 26/09/2000 Small modifications
02.00 F. Demaertelaere 12/02/2001 New logo
03.00 F. Demaertelaere 28/11/2002 Documentation platform independent
03.01 F. Demaertelaere 13/12/2002 After review
03.02 G. Van Overtveldt 04/04/2006 EAL 4+
04.00 Anna Papayan 14/10/2010 Methods of DEP Initialization, Security
mechanisms, Key generation in DEP
and export.
COPYRIGHT NOTICE
The information contained in this document is subject to change without notice. Atos Worldline
assumes no responsibility for any errors or omissions that may appear in this document. The contents
of this document must not be reproduced in any form whatever, by or on behalf of third parties,
without prior written consent of Atos Worldline.
1. TABLE OF CONTENTS
1. TABLE OF CONTENTS .................................................................................... 3

2. SCOPE OF THE DOCUMENT ......................................................................... 5
2.1. REFERENCES ................................................................................................... 5
2.2. CONTACTING ATOS WORLDLINE .......................................................... 6
3. PURPOSE OF THE DEP .................................................................................... 7
3.1. A CRYPTOGRAPHIC ACCELERATOR ................................................................ 7
3.1.1. Introduction............................................................................................ 7
3.1.2. The DEP Crypto Module ....................................................................... 7
3.2. A HOST SECURITY MODULE ........................................................................... 8
3.2.1. Introduction............................................................................................ 8
3.2.2. The DEP Host Security Module ............................................................. 9
4. APPLICATIONS ............................................................................................... 11
4.1. BASIC PRINCIPLES ......................................................................................... 11
4.1.1. Domains of Usage ................................................................................ 11
4.1.2. Software Development ......................................................................... 11
4.1.2.1. Atos Worldline Development .............................................................................. 11
4.1.2.2. Customer Development ......................................................................................... 12
4.2. EXAMPLES OF APPLICATIONS........................................................................ 13
4.2.1. Secure Communication ........................................................................ 13
4.2.2. PIN Generation/PIN Printing .............................................................. 13
4.2.3. Cardholder Authentication .................................................................. 14
4.2.4. Electronic Fund Transfer (EFT) .......................................................... 15
4.2.5. Super Smart Card ................................................................................ 16
5. THE DEP ENVIRONMENT ............................................................................ 17
5.1. INTRODUCTION ............................................................................................. 17
5.2. COMPONENT OVERVIEW ............................................................................... 17
5.2.1. The DEP Crypto Module ..................................................................... 17
5.2.2. The DEP Host Security Module ........................................................... 18
5.3. DETAILED COMPONENT DESCRIPTION .......................................................... 19
5.3.1. DEP Platform....................................................................................... 19
5.3.2. DEP Crypto Module ............................................................................ 21
5.3.3. C-ZAM/DEP Xentissimo ...................................................................... 22
5.3.4. DCC ..................................................................................................... 23
5.3.4.1. DCC List ............................................................................................................... 24
5.3.4.2. DCC Storage ......................................................................................................... 24
5.3.4.3. DCS ....................................................................................................................... 24
6. DEP INITIALIZATION ................................................................................... 25
6.1. INITIALIZATION METHOD BASED ON AUTHORITY KEYS ................................ 25
6.2. INITIALIZATION METHOD BASED ON ROLES IN DUAL CONTROL ................... 25
6.2.1. Identification and authentication ......................................................... 25
6.2.2. Loading keys in DEP Crypto Modules................................................. 26
6.3. MODES OF OPERATION ................................................................................. 27
6.3.1. Introduction.......................................................................................... 27
6.3.2. Development ........................................................................................ 27
6.3.3. Test ....................................................................................................... 27
6.3.4. Live ....................................................................................................... 28
6.4. AUTHORITY LEVELS ..................................................................................... 28
6.4.1. None ..................................................................................................... 28
6.4.2. Initial Authority Level .......................................................................... 29
6.4.3. Banksys Authority Level ....................................................................... 29
6.4.4. Customer Authority Level .................................................................... 29
7. ATOS WORLDLINE, THIRD PARTY AND DEBUG.................................... 30
8. KEYS & CAPABILITIES ................................................................................. 31
8.1. KEYS ............................................................................................................. 31
8.1.1. Introduction.......................................................................................... 31
8.1.2. Defining a Key List .............................................................................. 31
8.1.3. Defining a Key ..................................................................................... 31
8.1.4. Key generation in DEP and export ...................................................... 31
8.1.5. Storing on DCC.................................................................................... 32
8.1.6. Reconstructing a Key ........................................................................... 32
8.1.7. Loading the DEP Crypto Module ........................................................ 32
8.1.8. Backup Keys ......................................................................................... 32
8.1.9. Save/Restore Keys ................................................................................ 32
8.1.10. Using a Key .......................................................................................... 33
8.1.11. Temporary Host Key ............................................................................ 33
8.2. CAPABILITIES ................................................................................................ 33
8.2.1. Introduction.......................................................................................... 33
8.2.2. Defining a Capability List .................................................................... 34
8.2.3. Defining a Capability........................................................................... 34
8.2.4. Storing on DCC.................................................................................... 34
8.2.5. Reconstructing a Capability ................................................................ 34
8.2.6. Activating a Capability ........................................................................ 35
2. SCOPE OF THE DOCUMENT

This document describes the Atos Worldline DEP Environment in a general way. It is
meant for those who are not immediately familiar with the product.
It is the goal of this document that the reader gains an understanding of the purpose of
the product, its different components and the basics of its use. After reading the
document, the reader will be able to decide if the product is suitable for his/her
environment and will have an idea about the effort that it will take to set up and
maintain a DEP Environment.
First a definition is given of what is a Host Security Module (HSM) and how the DEP
fits in. In order to give an indication of the purpose of a HSM, some example
applications and uses of the DEP are outlined. Then an overview scheme of the DEP
Environment is shown, followed by a more detailed description of the different
components.
This document introduces the new products of Atos Worldline DEP Environment
based on Windows and Linux operating systems. The old products of DEP
Environment are not in wide use however there are customers who are still using DEP
Platforms (DEP/NT) based on Windows NT 4.0 operating system.
The last part contains an introduction to some security concepts used in the DEP
Environment: modes of operations, authority levels, keys and capabilities.
As already said, it is not the intention to give a detailed description of all the treated
subjects. Detailed information can be found in other documents referred to.
2.1. REFERENCES
This document contains references to other documents about the DEP. This paragraph
gives a list of all the documents referred to.
• DEP PC-AUX Program User Manual

• DEP/NMS User Manual
• DEP Software Cloning Guide
• DEP C-ZAM/DEP User Manual
• DEP Internal Communication System
• DEP/PCI Security Policy
• DEP Customer’s Security Officers Guide
There are no references made to the following documents, but they could be useful to
understand this document.
• DEP General Architecture

• DEP Glossary
2.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 www.banksys.com web page.
For support on issues related to DEP, customers, partners, resellers, and distributors
can send an email to the DEP Hotline:
mailto: dephotline-atosworldline@atosorigin.com.
3. PURPOSE OF THE DEP

3.1. A CRYPTOGRAPHIC ACCELERATOR
3.1.1. Introduction
A cryptographic accelerator is an additional hardware used to speed up cryptographic

calculations. The dedicated fast hardware does the time consuming and critical
cryptographic operations.
Applications running on a Personal Computer or a server could make use of the

cryptographic accelerator instead of implementing cryptographic algorithms in
software. Such software implementations are mostly slower than hardware
implementations and cannot offer the same level of security.
3.1.2. The DEP Crypto Module
Atos Worldline has developed a DEP Crypto Module that is used as a cryptographic
accelerator.
The DEP Crypto Module is a multi-chip embedded cryptographic module. It contains

a set of standard, production-quality IC chips that are interconnected. These ICs are
encapsulated in an epoxy potting and enveloped in a cold-rolled steel enclosure to
protect them from environmental or other physical damage.
The DEP Crypto Module (DEP/PCI) is able to store an Application Software and
Application Secrets.
The Application Secrets can either be generated internally or (secure) loaded from the
outside with the C-ZAM/DEP. This key management system is developed by Atos
Worldline: well considered, highly secure and based on many years of experience.
Both the Application Software and the Application Secrets are protected against
tampering, meaning that someone having physical access to the DEP Crypto Module
should not be able to obtain the secrets that are stored in it (Tamper Responsiveness
and Tamper Resistant).
The identity-based authentication mechanisms also used for secure loading of

Application Software in DEP Crypto Modules. The DEP Crypto Module authenticates
the identity of an operator and verifies that the identified operator is authorized to
assume a specific role and perform a corresponding set of services.
The operating system is designed with as main purpose to give the owner complete
assurance that the device does what is expected from it, nothing less, and (important
for a security device) certainly nothing more.
Hashing (SHS, SHA), encryption symmetric (DES, AES) and asymmetric (RSA up to
4096 bit, ECC) algorithms, random number generation and key generation are
implemented in “Banksys Crypto Core” hardware.
The DEP Crypto Module can be plugged in whatever Personal Computer or server.
Communication with the DEP Crypto Module is done through the PCI bus. The most
reliable, secure and user-friendly DEP Platform is DEP/T6 with DEP/PCI Crypto
Modules (2 DEP/PCI). When plugging the DEP Crypto Module in server, it is
recommended to use Linux server.
The DEP Crypto Module is completely developed by the Atos Worldline engineers
having many years of experience with information security systems. The DEP/PCI is
Common Criteria EAL3+ certified (begin 2003).
The DEP/PCI is FIPS140-2 certified DEP Crypto Module (for more information about
FIPS 140-2 refer to the DEP/PCI Security Policy document).
The illustration below shows the DEP/PCI, together with the key management device
C-ZAM/DEP.
3.2. A HOST SECURITY MODULE

3.2.1. Introduction
The purpose of a Host Security Module (HSM) is to store secret keys in it and to use
these keys in a strictly defined way. Moreover, a HSM supports the secure creation
of the secret keys that need to be stored in it and offers the functionality to load in a
secure way these keys in the protected environment of the device.
To meet these requirements it is necessary that a HSM is protected against

tampering, meaning that someone having physical access to the device should not be
able to obtain the secrets that are stored in it.
A Host Security Module should be seen as a “black box” connected to a host and
delivering cryptographic functions to the host. There could be different
communication means toward a HSM, e.g. serial communication, X25, TCP/IP, …
3.2.2. The DEP Host Security Module
The DEP HSM is a high secure and high speed HSM developed by Atos Worldline.
It is a DEP Platform (Industrial Computer) based on Linux or Windows operating
system. The DEP Crypto Module with the loaded Application Software is HSM that is
suited for various fields of application.
Using the DEP Crypto Module has the advantage that the whole security of the HSM
relies on the strong and proven security of the DEP Crypto Module, such as the
protection against tampering by using Tamper Responsiveness and Tamper Resistance
measures, secure loading of Application Software, a secure key management, a secure
internal operating system, …
It should be seen that the DEP Platform gives an added value to the DEP Crypto
Module to construct the HSM. Some examples of the added value features:
• support of one or more DEP Crypto Modules on one DEP Platform with a
mechanism that all the DEP Crypto Modules can be addressed individually
or as one pool (including load balancing)
• Graphical User Interface, the DEP/NMS application, for the management
of DEP Platforms and DEP Crypto Modules through the network.
• use of the standard DEP Platform communication interfaces (e.g. TCP/IP)
to talk with the DEP Crypto Modules
• buffering mechanism so that different commands can be sent in parallel to
the DEP Platform
The DEP Platform offers different means to communicate with the DEP Crypto
Module so that it can easily be connected to a host.
Two types of DEP Platforms are available so far: the DEP/T6, DEP/XP based on
Windows XP. And also user can integrate the DEP/PCI on the Linux server.
The DEP/NMS (Network Management System) application allows the management

and configuration of DEP Platforms and the DEP Crypto Modules. It is also used to
manage the pool of DEP Crypto Modules (loading software, taking traces,
backup/restore of keys, setting parameters, cloning the application software, etc).
Also the DEP/NMS application supports the cloning feature. The cloning feature is
used to transfer application software, keys, capabilities and all parameters of one (Master)
DEP Crypto Module to several selected DEP Crypto Modules to speed up the
configuration of DEP Crypto Modules with same set parameters. For more information
about the DEP Crypto Module(s) management refer to the DEP/NMS User Manual
and DEP Software Cloning Guide documents.
4. APPLICATIONS
4.1. BASIC PRINCIPLES
4.1.1. Domains of Usage
The DEP can be used in different domains and with different types of applications.
Examples are electronic and mobile commerce, communication through a secure pipe,
card and cardholder authentication, internet banking, card manufacturing, PIN
(Personal Identification Number) printing, key loading systems (e.g. smart cards,
terminals, …), PayTv applications, e-commerce, Public Key Infrastructure (PKI), …
The DEP Crypto Module is fully programmable and every security application within
memory range can run on the DEP.
All these applications can use cryptographic mechanisms with both symmetric (e.g.
using the (3)DES algorithm, AES) and asymmetric (e.g. using the RSA, or ECC
algorithm) keys.
The cryptographic functions of the DEP Crypto Module can be accessible using the
standard PKCS#11 API. This library is available for both Windows and Linux.
Atos Worldline follows the evolution of cryptographic algorithms and security

standards closely so other/future algorithms and standards will be supported when
necessary.
Although much more functions are available, the following functions are part of the
Common Criteria Certificate EAL3+ of the DEP/PCI:
• DES (56 bit) and 3DES (112/168 bit) – ECB, CBC and CFB modes (ANSI
X9.9, X9.32, X9.52)
• AES (128/192/256 bit) – ECB, CBC and CFB modes (ANSI X9.9, X9.32,
X9.52)
• SHA-1, SHA256, SHA224, SHA 384, SHA512, MD5
• RSA up to 4096 bit (ISO/IEC 9796-1, ISO/IEC 9796-2 and PKCS#1)
• Random Number Generation (meets the requirements listed in FIPS 140-2
Level 4 and the DIEHARD statistical tests)
• Key Generation (symmetric and asymmetric)
4.1.2. Software Development

4.1.2.1. Atos Worldline Development
Although Atos Worldline delivers standard applications, a customer has the option to
choose from standard libraries to create his specific Application Software. It is also
possible to ask Atos Worldline to implement customer specific functions on the DEP.
On demand, Atos Worldline can assist in defining reliable security architectures and
safe cryptographic functions for a customer’s specific application. Suggestions can be
made to use standard libraries, or customer specific specifications can be defined.
When dedicated developments are requested, they are always implemented on the
standard operating system of the DEP. The operating system contains the key
management system, the command parsing, the protection and the loading of
Application Software, …
During the software development process, the DEP specifications are defined by Atos
Worldline in collaboration with the requester. The Atos Worldline engineers that do
the development guarantee the security level of the delivered product and Software
Application.
During the many years of experience, Atos Worldline developed the cryptographic
support for different dedicated banking systems (electronic purse, debit and credit
card support, EMV, PIN management, …), card personalisation processes, electronic
and mobile commerce, key loading facilities, PKI functionality, …
4.1.2.2. Customer Development
In some circumstances and for whatever reason, the customer wants to develop his
own Software Application for the DEP. At that moment the customer will act as a
third party.
In this case, Atos Worldline can deliver a complete development environment to the
customer. (SDK) Only the DEP/PCI is supported in the development environment.
The development environment contains:
• dedicated hardware (DEP/PCI/Debug and C-ZAM/DEP/Debug)

• compilation and debug environment
• operating system and toolbox
• standard DEP/PCI Libraries
• sample application
• documentation and tools
Contact the DEP Product Manager for more information about the development
environment and possible training sessions.
4.2. EXAMPLES OF APPLICATIONS

This paragraph gives a non-exhaustive number of examples and could easily be
extended with other applications.
4.2.1. Secure Communication
When two systems communicate with each other over an insecure network, effort has
to be made to guarantee the confidentiality and the integrity of the messages sent
between those systems. Also, the identity of the message source must be verified.
Insecure Network
DEP DEP
SYSTEM 1 SYSTEM 2
To accomplish this, the DEP of the system sending the message will first encrypt it
(e.g. using a symmetric algorithm) to guarantee its confidentiality. Then, a Message
Authentication Code (MAC) is calculated over this encrypted message to ensure its
integrity. Finally, the identity of the sending system is proven by digitally signing the
message (e.g. with an asymmetric key).
The system receiving the message will forward it to its DEP, which will first verify
the sender’s identity and make sure the message has not been modified during
transport by verifying the MAC. When these checks have been successfully proven,
the message will be decrypted and treated.
Standard libraries are available for the DEP to ensure this kind of secure
communication between systems that have to communicate over insecure networks.
4.2.2. PIN Generation/PIN Printing
The DEP can be used for generating and printing Personal Identification Numbers
(PIN). PINs can for example be distributed to cardholders, and can then be used for
cardholder authentication.
The process is initiated by a host that sends a list of new cardholders to the DEP. For
each new cardholder a PIN has to be defined and printed.
In our example the DEP creates strong random PIN values. It could output the clear
PIN value on a serial port of the DEP Crypto Module (see paragraph 5.3.2 on page
21) or the serial port of the platform (via extra service) that is connected to a secured
printer. The printer prints the PIN on a paper and automatically glues a scratch-off on
the same position. Because the clear PIN never passes through the DEP Platform, only
the link between the DEP Crypto Module and the secured printer needs to be
protected physically.
DEP
secured printer PIN

PRINTING
SYSTEM
HOST
disk array
In another configuration, the DEP could return the PIN encrypted with a transport key
to the host. The host could then manage a secured printer by sending the encrypted
PIN to the secured printer. The secured printer contains also the transport key and is
thus able to decrypt the PIN just before printing it on paper.
DEP HOST
PIN
PRINTING
SYSTEM
secured printer
disk array
In addition to this, the DEP also outputs the PIN in another encrypted format. This
value needs to be stored together with the cardholder name in a table. This table is
sent to the server that needs to authenticate the cardholder afterwards.
4.2.3. Cardholder Authentication
In some environments, users log in on terminals/networks using a Personal

Identification Number (PIN) to prove their identity. Because it is not safe to send the
clear PIN value over the network, it is encrypted in the terminal (e.g. using a
(Derived) Unique Key Per Transaction ((D)UKPT)) and then sent to the
authentication server.
The authentication server contains a database with the names of all users and their
reference PIN (e.g. stored during a PIN Printing operation - see paragraph 4.2.2 on
page 13). The reference PIN is encrypted in such a way that only the DEP can retrieve
the clear value.
Customerx
Unsecure Network
PIN
TERMINAL
DEP
Customery
AUTHEN-
TICIATION Referencex
PIN
TERMINAL
SERVER PIN
DATABASE
Referencey
Customerz
PIN
PIN
TERMINAL
Referencez
PIN
The authentication server sends both the encrypted PINs (customer PIN coming from
the terminal and the reference PIN stored in the database) to the DEP/NT, where they
are both decrypted and compared. The result of this verification is digitally signed to
prove that the authentication server really verified the PIN. This value is sent back to
the terminal, as a proof of the user identity verification.
Of course, this system could easily be extended with other authentication (and
identification) methods such as biometrical authentication systems.
In addition to the cardholder authentication, a PIN change operation can be applied.
4.2.4. Electronic Fund Transfer (EFT)
Electronic Fund Transfer (EFT) is the mechanism of transferring “money” (funds)

from one place to another in an electronic way. This could be from a merchant to his
bank account, between two banks, from a bank account of a cardholder to his
electronic wallet, …
When transferring money from one place to another, it must be guaranteed that the
amount of money is not changed. This could be combined with authentication
mechanisms.
An example of the EFT system is an electronic purse. A cardholder loads money on

his electronic purse during an on-line communication with the bank. This amount of
money is deducted from his bank account. With the money on his electronic purse, the
cardholder can pay in shops, on vending machines, on payphones, … The money goes
from the electronic purse (off-line) into the terminal that is responsible for the
transaction handling. The terminal collects all the transactions and sends them in
batch to banks of the terminal owner.
BANK DEP
Unsecure Network
E-
E-E-PU
PU
PU RS
RSE
RS
E E
Unsecure
Communication
TERMINAL
The DEP delivers all the necessary cryptographic information to allow loading the
electronic money onto the electronic purse and to verify the cryptograms coming from
the terminal protecting the electronic transactions.
4.2.5. Super Smart Card
In some systems a smart card (or ICC) is used to provide cryptographic service to an
application, e.g. for identification purposes. Because of the capacity and performance
of the smart card, such a system is meant for a small scale (limited number of
identification processes in parallel). Of course, more smart cards could be added to
upgrade the scale of the system…
The DEP Crypto Module could be introduced to set-up the same system in a larger
environment. An Application Software needs to be developed on the DEP Crypto
Module that simulates the smart card to obtain a high speed “Super Smart Card”. A
step further could be to replace the “Super Smart Card” by a DEP Platform based on
the same DEP Crypto Module (and Application Software).
SCALE UPGRADE SCALE UPGRADE
APPLICATION SERVER APPLICATION SERVER
APPLICATION SERVER
DEP Platform DEP Platform

SMART SMART DEP/PCI DEP/PCI
CARD CARD DEP/ DEP/ DEP/ DEP/
PCI PCI PCI PCI
5. THE DEP ENVIRONMENT

5.1. INTRODUCTION
The DEP Environment is the collection of different components that are necessary to
manage, operate and use the DEP.
A distinction is made between the use of the DEP Crypto Module as an independent
device and the DEP Host Security Module.
The interaction between the different components and the components themselves are
explained below.
5.2. COMPONENT OVERVIEW

5.2.1. The DEP Crypto Module
The DEP Environment of the independent DEP Crypto Module consists of the DEP
Crypto Module, the C-ZAM/DEP and the DCCs.
A host requiring cryptographic support communicates directly with the DEP Crypto
Module.
• The DEP Crypto Module is the actual secured device containing the secret keys
and an Application Software that allows executing specific cryptographic
operations using these keys.
• The C-ZAM/DEP is a secure input device that loads the necessary parameters and
secret keys in the DEP Crypto Module. It also contains a smart card reader to read
these parameters and secrets from DCCs. It should be seen as the keyboard,
display and card reader of the DEP Crypto Module.
• The DCC (DEP Control Card) is a smart card used for storage purposes. They are
read or written by using the C-ZAM/DEP. There are three different types:
 a DCC List containing lists of parameters and keys together with their
properties (no secret information)
 a DCC Storage containing (a part of) the actual parameters and key values
in encrypted format (secret/sensitive information)
 a DCS (Dual Control Storage) containing (a part of) Customer

Administrators’ credentials with their K_AWLs and Check Values, the secret
key parts for key reconstruction and the credentials of software-loading
operators. K_AWL keys are AES 256-bits keys, used to protect the loading of
DEP Application Software.
5.2.2. The DEP Host Security Module
The DEP Environment of the DEP Host Security Module consists of the DEP
Platform, the DEP Crypto Module, the C-ZAM/DEP and the DCCs.
A host requiring cryptographic support communicates directly with the DEP Platform.
The DEP Platform can be a:
1. DEP/T6
2. DEP/XP running on Windows XP operation system
3. DEP/Linux
Containing at least one DEP Crypto Module (maximum four/two for T6). It takes care
of the communication between the DEP Crypto Module and the host and allows some
supervision, configuration and diagnostic operations. In addition, it can deliver some
extended services (see paragraph 5.3.1 on page 19).
DEP/T6 Platform:
The DEP/T6 is a powerful cryptographic appliance, designed for a wide range of

security services in the field of strong authentication, data integrity, authentication and
confidentiality protection. The DEP/T6 takes its exceptional cryptographic power
from two of Atos Worldline' state-of-the-art DEP/PCI Hardware Security Modules.
As to the security features, the DEP/T6 inherits from the DEP/PCI very sophisticated
and sensitive protection mechanisms against tampering.
Information about the DEP Crypto Module, C-ZAM/DEP and DCCs can be found in
paragraph 5.2.1 on page 17.
5.3. DETAILED COMPONENT DESCRIPTION

This paragraph contains a more detailed description of the different components of the
DEP Environment.
5.3.1. DEP Platform
The DEP Platform is a Windows or Linux based PC that acts as Host Security Module
(HSM). But the DEP Platform system does not rely on this PC for any security
aspects. The DEP Crypto Module(s) and the C-ZAM/DEP guarantee the security.
The DEP Platform can contain up to four separate DEP Crypto Modules, each
connected to PCI (DEP/PCI) slot. The DEP Platform also contains at least one
communication card to connect to the HOST.
DEP Platform
Pre-Processing
HOST
Communication
DEP Crypto
CZAM/DEP Card
Module
Post- Processing
Communication
... Card HOST
...
DEP Crypto
Module
DEP Platform
Operating
System (XP/
DEP Crypto Linux/WinNT)
Module
DEP Crypto DEP/NMS Host Interface DEP Handler

Module Supervision Supervision
The DEP/NMS application is used as a Graphical User Interface (see DEP/NMS User
Manual document) for DEP Platforms configuration, diagnostic and supervision
purposes.
The PC-based solution also has other advantages.
• It provides an increased flexibility in communication channels. It is easy to

connect the DEP Platform to the host because there is a choice from a
variety of default communication protocols (TCP/IP, PDP Asynchronous
(serial RS232 based)).
• Pre-processing and post-processing operations that don’t need the high

security of the DEP Crypto Module are implemented (e.g. hashing
algorithms,...) on the DEP Platform. It is even possible to integrate
additional hardware. Additional hardware and/or processes could be called
directly from the host and/or the DEP Crypto Module could make use of
these services. Refer to the document DEP Internal Communication System
for more information.
• Because the security does not rely on the DEP Platform part, the
management features such as remote control has been implemented
(DEP/NMS).
5.3.2. DEP Crypto Module
The DEP Crypto Module is loaded with cryptographic keys and with Application
Software that provides cryptographic functions. Its purpose is to perform all security
operations requested by the host.
The DEP/PCI Crypto Module v4.0 is the most recent one and FIPS 140-2 Level 3
certified.
The DEP Crypto Module is a secure, tamper responsive device that consists of two
dedicated processors:
• The main processor runs the loaded Application Software on a native processor
and executes commands coming from the host. It can rely on build-in
coprocessors for all cryptographic needs.
• The alarm processor ensures the safety of all data stored in the DEP Crypto
Module. It detects all physical intrusions and reacts to these security breaches
by deleting all software and cryptographic keys from the memory of the main
processor. Alarms become active when
. the wiring enveloping of the DEP Crypto Module is cut,
. the temperature goes out of a specific range,
. the DEP Crypto Module is moved or lifted,
. its cabinet is opened,
. the batteries are disconnected,
. the batteries’ capacity decreased to a certain level,
. and the power supply voltage becomes to low/high.
DEP Crypto Module
CZAM
DEP MAIN DEP ALARM

C-ZAM/DEP AUX1
AUX2
DEP Platform
The DEP Crypto Module has three communication connectors:
• The CZAM port connects a C-ZAM/DEP to the main processor of the DEP
Crypto Module to provide a secure link. This connection is used to load
keys and capabilities that are present in the C-ZAM/DEP into the DEP
Crypto Module.
• AUX 2 connects a C-ZAM/DEP or a PC to the alarm processor of the DEP

Crypto Module. This connection can be used to read alarm information
from the alarm processor.
• AUX 1 is reserved as a debug channel during development of Application

Software.
The DEP Crypto Module is connected to the DEP Platform via PCI bus. This
connection is used for loading application software in the DEP Crypto Module, for
backup and restore of the Application Secrets and for the actual calling of the
cryptographic functions of the Application Software.
5.3.3. C-ZAM/DEP Xentissimo
Since it is not secure to use a DEP Platform’s keyboard and display for entering secret
values or for displaying them, the C-ZAM/DEP has been introduced. The C-
ZAM/DEP should be seen as the secure keyboard and display of the DEP Platform
and is directly and securely linked with the DEP Crypto Module (see paragraph 5.3.2
on page 21).
In addition, the C-ZAM/DEP contains a chip card reader. This allows the storage of
(secret) information such as parameters, keys, … on chip cards.
The actual secret values can be generated internally in the C-ZAM/DEP or can be
entered via its keyboard.
These values can be transferred in a secure way to the DEP Crypto Module for the use
in an Application Software or to a DCC for secure storage. Of course it is also
possible to read these values again from DCC.
All the communication between the C-ZAM/DEP and the other devices is
cryptographically protected (except reading the status of the alarm processor).
Refer to the DEP C-ZAM/DEP User Manual for more information about the C-
ZAM/DEP.
5.3.4. DCC
A DEP Control Card (DCC) is a smart card that is used to store all kinds of
parameters and values used in a DEP Environment. It is considered a secure and
tamper resistant device.
They are used as a backup device to store secret and non-secret values. The security
of the system does not rely on the tamper resistance of the DCC for the storage of the
secret values: all the values are encrypted before being written on the DCC.
Interaction with the DCC is always done through the C-ZAM/DEP.
As already mentioned above, there are three types of DCCs: DCC List, DCC Storage
and Dual Control Storage (DCS).
5.3.4.1. DCC List
The DCC List contains lists of parameters and keys (together with their properties)
that are used in a specific DEP Environment. An example of a property is the secret
sharing scheme used to distribute the secret among different persons or the list of
identifications (tags) of the keys used by the Application Software.
These lists are not considered secret information and are therefore not secure.
5.3.4.2. DCC Storage
The DCC Storage is used to store secret keys and confidential parameters (such as
keys and capabilities).
It is possible that secret values (keys or capabilities) are divided in several parts,
which are then stored on different DCC Storage cards. This secret sharing principle
can be used to distribute the secret among different people. To reconstruct the secret
value in the C-ZAM/DEP, a previously defined number of parts are required.
The dividing of a secret value in parts is done following a secret sharing scheme,
which is read from a DCC List.
DCC List C-ZAM/DEP
Secret Sharing
Scheme Secret Sharing Scheme
DCC Storage
Secret Sharing
Secret Part 1 Algorithm
...
Secret Part n
Secret
DCC Storage
5.3.4.3.DCS
The DCS (Dual Control Storage) contains all the information and secrets of the
Customer Administrators and Software-Loading operators, such as the credentials,
K_AWLs and secret key-parts of Customer Administrators.
The DCS is used to manage the DEP Crypto Modules in dual control (FIPS certified
method). Passwords and key parts are written in clear.
The DCSs are PIN-protected for both read and write operations.
6. DEP INITIALIZATION
Two methods of initialization are supported.
6.1. INITIALIZATION METHOD BASED ON AUTHORITY

KEYS
The DEP Crypto Module needs to be initialized for a specific customer. The
Authority Keys is used to protect the communication between different devices of
DEP Environment (DEP Crypto Modules, C-ZAM/DEP, DCCs).
This task has to be performed only once, when setting up the first DEP Environment.
At the Boot level during the Initial (INIT) Authority level the Init Authority keys,
hard-coded in the DEP Crypto Module, become operational (see 6.4.2 on page 29).
At the Banksys (BKS) Authority Level the (3)DES keys that are defined by the Atos
Worldline’ Security Officers become operational (see 6.4.3 on page 29).
At the Customer (CUST) Authority Level, (3)DES keys that are defined by Security
Officers of the customer become operational (see 6.4.4 on page 29).
Only if the device is in the CUST Authority Level, secrets can be loaded in DEP
Application Software.
To initialize the DEP Environment the Customer Administrator should define the
unique CUST Authority Keys.
After bringing the DEP Crypto Module to CUST Authority level the Software Load
Capability should be activated to be able to load the Application Software in DEP
Crypto Module. The Software Load Capability protects the load operation. Now if the
Application Software is loaded the keys and capabilities need to be loaded into the
DEP Crypto Module to perform cryptographic operations.
6.2. INITIALIZATION METHOD BASED ON ROLES IN

DUAL CONTROL
6.2.1. Identification and authentication
Authentication data within a cryptographic module shall be protected against

unauthorized disclosure, modification, and substitution.
The identity-based authentication mechanisms are supported by a DEP Crypto

Module. The DEP Crypto Module has two operator roles: Customer Administrator
role (Crypto Officer) and Software loading operator role (User role). A cryptographic
module authenticates the identity of an operator and verifies that the identified
operator is authorized to assume a specific role and perform a corresponding set of
services.
If the DEP Crypto Module is powered off at the initialization process, the results of
previous authentications are not retained and the DEP Crypto Module will require the
Customer Administrators and Software-Loading operators to be re-authenticated.
The Customer Administrators received their pre-expired usernames and passwords

from Atos Worldline on paper in separate envelopes, to be used as initial
authentication credential.
Two customer administrators are necessary to initialize the DEP Crypto Module,
which allows to protect sensitive functions and information.
After authenticating the customer administrators should change their pre-expired

passwords and usernames (see DEP Customer’s Security Officer’s Guide document).
With the pre-expired passwords and usernames the customer administrators also
receive KAWL keys and Check Values from Atos Worldline. Atos Worldline
generates KAWL keys, divides it in two components and gives them with Check
Values in clear to the customer administrators on paper, in two separate envelopes.
For the software-loading operations there should be a group of software-loaders. Two

customer administrators together create the specialized group of software-loading
operators. There can be several operators, but a minimum of 2 operators is necessary
for security reasons, i.e. the customer administrator will define 2/6, which means that
6 operators are really defined, but only 2 are necessary to load the software.
6.2.2. Loading keys in DEP Crypto Modules
To activate the DEP Application Software the CUST Authority Keys should be
loaded in DEP Crypto Module.
Authority keys are a set of keys used to execute functions coupled to a certain
Authority Level. Authority Keys protect the communication between the different
devices in the DEP Environment (C-ZAM/DEP, DCC and DEP Crypto Module). The
first task the Customer’s Security Officer has to perform when receiving a DEP
Environment is to define its unique CUST Authority Keys. The CUST Authority Keys
are generated in the C-ZAM/DEP (for more information refer to the DEP Customer’s
Security Officer’s Guide).
The keys divided according to the selected Secret Sharing Scheme and distributed to
the customer administrators should be loaded in DEP Crypto Module in dual control
mode. It is the responsibility of the Customer’s Security Officer to distribute the
sensitive information to different people.
6.3. MODES OF OPERATION

6.3.1. Introduction
The DEP Environment (i.e. the DEP Platform, DEP Crypto Module, C-ZAM/DEP
and DCCs) can operate in different modes of operation. Once a device is put in a
specific mode of operation, it is not possible to switch to another one without deleting
all secret values already entered in the different devices.
Every mode has its own set of Initial Authority Keys (see paragraph 6.4 on page 28
for more information about the Authority Keys).
DEV TST LIV
NO NO NO
INIT INIT INIT
BKS BKS BKS
CUST CUST CUST
The purpose is to be able to have completely separated environments for different

purposes.
The different modes of operation are:
• Development
• Test
• Live
6.3.2. Development
The development mode (DEV) is used only internally at Atos Worldline by the
development teams or by customers developing their own Application Software.
This mode skips certain verifications (such as software load certificates, …) to

facilitate development.
6.3.3. Test
This operation mode (TST) can be used by customers when setting up a test
environment, using known test values instead of secret values that are not known.
Atos Worldline can give the values of the ‘test secrets’ to customers, so they can
follow the complete security chain. This comes in handy when debugging or
troubleshooting the applications or architectures of the customer.
It is strongly recommended to avoid loading real applications keys on a DEP

Environment working in TST mode! It should be considered that all the key values of
such a system are known/traceable.
6.3.4. Live
In this mode (LIV), the real secrets used in the real-time environment are used. It is
not possible to recover any of the secrets that are defined in this mode.
Except for the values of the keys, there is no difference between TST mode and LIV
mode. This guarantees a smooth changeover from the test environment to a live
environment.
It is highly recommended to set up a test environment, using mode of operation TST

to completely check out the applications before proceeding to LIV mode.
6.4. AUTHORITY LEVELS

The Authority Level defines the owner of the secrets loaded in a device of the DEP
Environment at that time. Only the entity that can prove that he knows the secrets of
the Authority Level has the right to execute specific functionality.
The Authority Level mechanism is present in the DCCs, the C-ZAM/DEP and the
DEP Crypto Module. The keys of the Authority Levels are used to protect the
communication between the different devices.
The different authority levels are:
• None
• Initial Authority Level (INIT)
• Banksys Authority Level (BKS)
• Customer Authority Level (CUST)
6.4.1. None
At this time, no secrets of the device are operational yet.

6.4.2. Initial Authority Level
During the Initial (INIT) Authority Level, keys that are hard-coded in the DEP
Environment become operational. The code of the DEP Crypto Modules is kept
confidential and only the Atos Worldline engineers responsible for a specific device
have access to the source code of that device.
These keys are different for the different modes of operation (DEV, TST, and LIV).
6.4.3. Banksys Authority Level
At the Banksys (BKS) Authority Level, keys that are defined by the Atos Worldline
Security Officers become operational. These keys are generated randomly and replace
the keys of INIT Authority Level.
Customers receive their devices in BKS Authority Level, or they obtain from Atos
Worldline the necessary values to transfer the device to BKS Authority Level.
Atos Worldline guarantees that the secret values of the BKS Authority Level are only
known by the responsible Atos Worldline Security Officer. Every customer receives
another Banksys Authority Key.
These keys are different for the different modes of operation (DEV, TST, and LIV).
6.4.4. Customer Authority Level
At the Customer (CUST) Authority Level, keys that are defined by Security Officers
of the customer become operational. They replace the keys defined by Atos
Worldline of BKS Authority Level. Again, these keys are generated randomly.
This operation can only be done when owning a specific capability. This capability
could be created by Atos Worldline and given to the customer.
Only at this level parameters and keys can be loaded, and the host can start using the
DEP Environment for its cryptographic operations.
It is strongly recommended that these keys are different for the different modes of
operation (DEV, TST, and LIV).
7. ATOS WORLDLINE, THIRD PARTY AND

DEBUG
As already mentioned in paragraph 4.1.2.2 on page 12, it is possible that customers
develop their own software on the DEP Crypto Module (only DEP/PCI). Therefore,
Atos Worldline has created a three-fold DEP/PCI product range.
The only difference between the three DEP/PCI product ranges is the values of the
Initial Authority Keys in Live mode.
/Atos Worldline /Third Party /Debug

DEBUG A A A
TEST B B B
LIVE C D 0
The Debug range is only required for developing Software Applications. Therefore a
DEP/PCI/Debug and a C-ZAM/DEP/Debug are required. The Live Initial Authority
Keys are set to zero.
Products (including Software Applications) delivered by Atos Worldline make part

of the Banksys range. This means that Atos Worldline is responsible for the
distribution of the hardware and the Software Applications, delivering a product based
on the DEP/PCI/Banksys and C-ZAM/DEP/Banksys.
When Third Parties develop Software Applications, there are two possibilities: either
the Application Software is distributed by (and under control of) Atos Worldline or
the Third Party distributes its own product based on the DEP/PCI. In the first case, the
product makes part of the Banksys range. In the latter case a Third Party range
(DEP/PCI/Third Party and C-ZAM/DEP/Third Party) is delivered to the Third Party
that redistributes it to its customers. The Third Party is then responsible of the final
product.
8. KEYS & CAPABILITIES

8.1. KEYS
8.1.1. Introduction
The main purpose of a HSM is to execute cryptographic operations using secret keys
specific for that operation. These keys are called Application Keys.
Other keys are used by the DEP Environment. These keys protect the Application
Keys and the communication between DCC, C-ZAM/DEP and DEP Crypto Module.
They are called the Authority Keys.
The following paragraphs give a brief overview of the life cycle of Application Keys.
8.1.2. Defining a Key List
A list of keys does not contain secret information and can be created on PC for easy
editing, using a program delivered by Atos Worldline (for more information refer to
the DEP PC-AUX Program User Manual document). The list can then be sent to the
C-ZAM/DEP.
This list contains all the properties of the keys (identification tag, name, type, length,
secret sharing scheme and how the key value is generated). The properties of a key
form a Key Definition List that must be present in the C-ZAM/DEP before the key
can be defined. Optionally, the Key Definition List can be kept on a DCC List.
8.1.3. Defining a Key
The key definition is always done in the C-ZAM/DEP 1.
All the properties of the key are linked with the corresponding secret key value.
Depending on the Key Definition List, the key value can be entered manually in the
C-ZAM/DEP (and the Key Definition List defines how it is entered) or can be
generated randomly by the DEP Environment.
8.1.4. Key generation in DEP and export
1
There is an exception for RSA keys. It is possible that these keys are internally generated in the DEP
Crypto Module (performance reason). The public key part can be exported in clear text and the
complete key pair can be stored in the key table and possibly be output in a secure way.
For all those who require FIPS compliance, their keys should have the KR field SET
(Key Reconstruction in DEP) in the Definition List(s) (see 8.1.2 on page 31).
Keys can be generated and component-split directly in the DEP Crypto Module and
exported in clear component to DCS or CZAM/DEP screen. Key components also
should be reconstructed directly in DEP Crypto Module.
For splitting into components, both XOR and Secret Sharing schemes are supported.
For more information about Key generation in DEP refer to the C-ZAM/DEP User
Manual document.
8.1.5. Storing on DCC
Optionally, secret key values can be written from C-ZAM/DEP on DCC Storage. Of
course, the keys are encrypted before being written on DCC.
They can be written in one part on one DCC, or they can be divided in different parts
and distributed over several DCCs. This depends on the secret sharing scheme that is
defined in the Key Definition List. Different types of secret sharing can be defined in
the Key Definition List.
8.1.6. Reconstructing a Key
The act of reconstructing a key can be done in the C-ZAM/DEP or in DEP Crypto
Module.
As mentioned in paragraph 8.1.5, the value of the key can be spread over different
DCCs using a secret sharing mechanism. To reconstruct a key, the necessary DCCs
need to be inserted into the C-ZAM/DEP.
8.1.7. Loading the DEP Crypto Module
Keys that are present in the C-ZAM/DEP (either entered manually or read from DCC)
should be loaded in the DEP Crypto Module over the secure link between the C-
ZAM/DEP and the DEP Crypto Module.
8.1.8. Backup Keys
To facilitate the loading of keys when a DEP has to be reloaded, it is possible to

backup all Application Keys (except the DEP Master Key) in a file. The permission
(capability) to create a backup and the confidentiality of it are fully protected using
encryption with a customer-defined key (DEP Master Key).
8.1.9. Save/Restore Keys

A key backup can be reloaded in the DEP Crypto Module. The permission
(capability) to restore the backup and the customer defined key used for encrypting
the backup (DEP Master Key) have to be loaded beforehand with the C-ZAM/DEP in
the DEP Crypto Module.
8.1.10. Using a Key
Application Keys that are present in the DEP Crypto Module can be used by the
Application Software.
Usage of keys by the cryptographic operations is under complete control of the

Application Software. Their use can be extra protected so they can only be used if the
necessary permissions to do so are also loaded by the C-ZAM/DEP in the DEP Crypto
Module.
8.1.11.Temporary Host Key
In the HKD concept, keys are stored in the Host Key Database, encrypted under a
Host Master Key (HMK). The form under which the key is stored in the HKD is
called ‘Key Token’. Key tokens are downloaded into the DEP for being used as
cryptographic keys. The download is temporary, i.e. the downloaded keys persist in
the DEP secure memory only for the time necessary for the execution of the DEP call.
This is in contrast to the DKT concept, where keys are permanently stored in the DEP
Key Table. DKT is the table with the permanent application key data. When a DEP
interface needs a cryptographic key, it first looks for this key in the DEP Key Table. If
the key is not found, then the DEP looks for the key in the secure memory reserved
for temporary ‘downloaded’ keys. In other words, keys from the DEP Key Table have
priority on keys from the Host Key Database.
8.2. CAPABILITIES
8.2.1. Introduction
Capabilities represent the right to perform certain (security) actions on the DEP
Crypto Module or the C-ZAM/DEP.
They can be stored on DCCs or recreated when required. When they are loaded in the
C-ZAM/DEP or forwarded from C-ZAM/DEP to DEP Crypto Module, the capability
becomes active after correct verification. Then the corresponding action can be
executed.
During the creation of a capability on the C-ZAM/DEP, the preferred lifetime of the
capability should be chosen. Capabilities can be set to be active as long they are
loaded, or they can be limited in time or in the number of operations that can be
performed with them.
Examples of capabilities are:

• the right to load specific Application Software in a DEP Crypto Module

• the right to load specific Application Keys in a DEP Crypto Module containing
a specific Application Software
• the right to use a specific function of an Application Software
• the right to define Application Keys in the C-ZAM/DEP
• …
The following paragraphs give a brief overview of the life cycle of capabilities.
8.2.2. Defining a Capability List
A list of capabilities does not contain secret information and can be created on PC for
easy editing, using a program delivered by Atos Worldline (for more information
refer to the DEP PC-AUX Program User Manual document). The list can then be sent
to the C-ZAM/DEP.
This list contains all the properties of the capabilities (identification tag, name and
secret sharing scheme). The properties of all capabilities form a Capability Definition
List that must be present in the C-ZAM/DEP before the capability can be defined.
Optionally, the Capability Definition List can be kept on a DCC List.
8.2.3. Defining a Capability
The act of defining a capability is always done in the C-ZAM/DEP.
All the parameters (e.g. lifetime) of the capability are cryptographically secured.
8.2.4. Storing on DCC
Optionally, capabilities can be written from C-ZAM/DEP on a DCC Storage. Of

course, the capabilities are encrypted before being written on DCC.
They can be written in one part on one DCC, or they can be divided in several parts
and distributed over several DCCs. This depends on the secret sharing scheme that is
defined in the Capability Definition List. Different types of secret sharing can be
defined in the Capability Definition List.
8.2.5. Reconstructing a Capability
The act of reconstructing a capability is always done in the C-ZAM/DEP.

As mentioned in paragraph 8.2.4, the capability can be spread over different DCCs
using a secret sharing mechanism. To reconstruct a capability, the necessary DCCs to
reconstruct the capability need to be inserted into the C-ZAM/DEP.
8.2.6. Activating a Capability
Immediately after the reconstruction, the capability will be verified and activated
when the verification proved to be correct.
A C-ZAM/DEP capability will be verified in the C-ZAM/DEP itself, a DEP capability

will be sent to the DEP Crypto Module for verification.
Once the verification succeeded, the capability will be activated and the
corresponding action can be performed.

Introduction To DEP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To DEP

Uploaded by

Copyright:

Available Formats

Haachtsesteenweg 1442

Version: 04.00 Classification: Public

Version Management Report

1. TABLE OF CONTENTS .................................................................................... 3

2. SCOPE OF THE DOCUMENT

• DEP PC-AUX Program User Manual

• DEP General Architecture

2.2. CONTACTING ATOS WORLDLINE

For the documentation visit www.banksys.com web page.

3. PURPOSE OF THE DEP

A cryptographic accelerator is an additional hardware used to speed up cryptographic

Applications running on a Personal Computer or a server could make use of the

3.1.2. The DEP Crypto Module

The DEP Crypto Module is a multi-chip embedded cryptographic module. It contains

The identity-based authentication mechanisms also used for secure loading of

3.2. A HOST SECURITY MODULE

To meet these requirements it is necessary that a HSM is protected against

3.2.2. The DEP Host Security Module

The DEP/NMS (Network Management System) application allows the management

Atos Worldline follows the evolution of cryptographic algorithms and security

4.1.2. Software Development

4.1.2.2. Customer Development

• dedicated hardware (DEP/PCI/Debug and C-ZAM/DEP/Debug)

4.2. EXAMPLES OF APPLICATIONS

4.2.1. Secure Communication

4.2.2. PIN Generation/PIN Printing

secured printer PIN

4.2.3. Cardholder Authentication

In some environments, users log in on terminals/networks using a Personal

In addition to the cardholder authentication, a PIN change operation can be applied.

4.2.4. Electronic Fund Transfer (EFT)

Electronic Fund Transfer (EFT) is the mechanism of transferring “money” (funds)

An example of the EFT system is an electronic purse. A cardholder loads money on

4.2.5. Super Smart Card

SCALE UPGRADE SCALE UPGRADE

APPLICATION SERVER APPLICATION SERVER

DEP Platform DEP Platform

5. THE DEP ENVIRONMENT

5.2. COMPONENT OVERVIEW

 a DCS (Dual Control Storage) containing (a part of) Customer

5.2.2. The DEP Host Security Module

The DEP Platform can be a:

The DEP/T6 is a powerful cryptographic appliance, designed for a wide range of

5.3. DETAILED COMPONENT DESCRIPTION

5.3.1. DEP Platform

... Card HOST

DEP Crypto DEP/NMS Host Interface DEP Handler

The PC-based solution also has other advantages.

• It provides an increased flexibility in communication channels. It is easy to

• Pre-processing and post-processing operations that don’t need the high

5.3.2. DEP Crypto Module

DEP Crypto Module

DEP MAIN DEP ALARM

The DEP Crypto Module has three communication connectors:

• AUX 2 connects a C-ZAM/DEP or a PC to the alarm processor of the DEP

• AUX 1 is reserved as a debug channel during development of Application

5.3.3. C-ZAM/DEP Xentissimo

Interaction with the DCC is always done through the C-ZAM/DEP.

5.3.4.1. DCC List

5.3.4.2. DCC Storage

6.1. INITIALIZATION METHOD BASED ON AUTHORITY

6.2. INITIALIZATION METHOD BASED ON ROLES IN

6.2.1. Identification and authentication