Page 19

Cyberflex Access E-gate V3

Cryptographic Module Security Policy

SEP

Applicable on: 16 April 2007

Ref: SP_D1033918.doc

Rev:1.0

Page 19/24

This document may be reproduced only in its original entirety (without revision).

6.3.2 Applet Loading with "GP DAP"

In this case, the Issuer (Crypto Officer) loads the applet owned by the Applet provider. The Issuer knows that the

applet is correct because he loads it inside a secure channel with his own keys, thereby ensuring the applet Origin and

Integrity. The Cyberflex Access E-gate V3 cryptographic module provides a mechanism designated as "DAP" in

[GP211] to give the same confidence to the Applet provider.

This mechanism uses a DAP, computed off-module by the Applet provider and loaded by the Issuer along with the

applet. This DAP is then verified on-module with the Applet Provider`s keys, thereby ensuring that the applet loaded

onto the module is the one given by the Applet Provider. DAP verification is done systematically at the end of loading,

without any additional command.

The Cyberflex Access E-gate V3 cryptographic module provides two methods of DAP implementation, "GP DAP DES"

and "GP DAP RSA". Only one of them is used when loading an applet.

"GP DAP DES" works as an EDC that verifies integrity of the applet on behalf of the applet provider. It is made of a

series of DES computations, ended by a TDES computation. All DES and TDES operations use TDES DAP secret

key. This TDES DAP key is loaded by the User/Applet Provider in his Security Domain, with the PUT DES KEY

command. This TDES DAP key cannot be updated.

"GP DAP RSA" is a signature verification, which is a stronger mechanism than the "GP DAP DES". It verifies the

integrity of the applet on behalf of the applet provider and it also authenticates the applet provider as the originator

of the applet. It is the RSA PKCS#1 Signature of SHA-1 message Digest of the applet. The RSA operation uses the

applet provider`s public key. This RSA DAP key is loaded by the User/Applet Provider in his Security Domain, with

the PUT RSA KEY command. This key cannot be updated.

6.3.3 Applet Loading with Delegated Management (DM)

In this case, the Applet provider loads his own applet. The Cyberflex Access E-gate V3 cryptographic module provides

the Delegated Management (DM) feature as defined in [VOPS]. This feature enables the applet provider to load onto

the cryptographic module an applet previously validated by the Issuer (Crypto Officer).

The DM uses two cryptographic mechanisms:

A Token computation and verification

A Token, also called "GP DAP RSA" is an RSA signature computed off-module by the Issuer (Crypto Officer) to

allow the loading of this applet. The applet provider sends this Token along with the applet. On-module, the Card

Manager verifies the token to check the Origin of the applet, (i.e. that the applet has been authorized by the Issuer)

and the integrity of the applet. The Token verification operation uses the Issuer`s RSA DM public key. This key is

loaded in the Crypto Officer Security Domain with a PUT RSA KEY command. This key cannot be updated.

A Receipt computation and verification

A Receipt is sent to the Issuer via the applet provider to confirm that the loading operations were done as

expected. This Receipt contains data followed by an EDC. This EDC is made of a series of DES, ended by a

TDES. All the DES and TDES operations use the Issuer`s TDES DM key. This TDES DM key is loaded in the

Crypto Officer Security Domain with a PUT DES KEY command. This key cannot be updated.

The DM mechanism is optional but it is designed to be used in FIPS mode of operation.

It is described in detail in the CO / User Guidance document.