| |
Table of Contents
A. Introduction to TokenKeys
B. Setting Up a TokenKey CA
C. Setting Up a TokenKey TKS
D. Setting Up a TokenKey TPS
E. Setting Up Cloning for a TokenKey CMS Subsystem
F. Setting Up Connection FailOver in an TokenKey TPS
G. Setting Up a TokenKey Client
H. Setting up TokenKey Key Change Over
I. Setting up TokenKey Applet Update
TokenKeys consist of two unique token types: deviceKey and userKey.
Operations supported by userKey consist of enrollment, pin reset,
and format. Operations supported by deviceKey operations consist of
enrollment and format.
The release notes contain instructions on how to download all the
necessary components, such as CMS, tps.zip, and esc.zip, to set up a
TokenKey infrastructure.
1. Introduction:
CMS 7.0 has added profile plugins to support the two types of TokenKey
enrollments. Although the package works "out of the box", careful
examination of the default profiles is highly recommended to fit your needs.
For this example, an CMS TokenKey CA will be installed and configured.
2. How to install/configure an CMS TokenKey CA
a. Setup the CMS TokenKey CA as usual (per the CMS 7.0 installation
procedure). Install the CMS TokenKey CA in the <ca-server-root>.
b. After you finish configuring the CMS TokenKey CA, you need to do the
following:
i. As an administrator, go to the administration console:
a. Add a special "agent" user on the CMS TokenKey CA
(e. g. "TPS Trust Entity") - [Configuration] [Users and Groups]
[Users] [Add]. At "Edit User Information", enter all info
(phone number and email are optional), including full name
(e. g. "TPS Trust Entity").
b. Still at the "Edit User Information", select the
"Certificate Manager Agents" group.
ii. Review certificate profiles. On the admin console, look under
the certificate profiles "caTokenDeviceKeyEnrollment,"
"caTokenUserSigningKeyEnrollment," and "caTokenUserEncryptionKeyEnrollment"
and determine if customization for each field is needed.
NOTE: These profiles are located in the
"<ca-server-root>/cert-<id>/profiles/ca/"
directory.
The profiles allow you to control what goes into the certificate.
You may optionally configure a subject name constraint policy
in the profile to retrieve information from a user ldap database.
For example, in the default caTokenUserEncryptionKeyEnrollment.cfg in
"<ca-server-root>/cert-<id>/profiles/ca/", the following tells the
CA to put uid and user email into the subject name of the certificate
in the pattern provided.
policyset.set1.p1.default.params.dnpattern=UID=$request.uid$, E=$request.mail$, O=Token Key User
#policyset.set1.p1.default.params.dnpattern=UID=$request.uid$,
O=Token Key User
#changed ldap.enable to true to support SMIME
policyset.set1.p1.default.params.ldap.enable=true
policyset.set1.p1.default.params.ldap.searchName=uid
policyset.set1.p1.default.params.ldapStringAttributes=uid,mail
policyset.set1.p1.default.params.ldap.basedn=dc=com
policyset.set1.p1.default.params.ldap.maxConns=4
policyset.set1.p1.default.params.ldap.minConns=1
policyset.set1.p1.default.params.ldap.ldapconn.Version=2
policyset.set1.p1.default.params.ldap.ldapconn.host=<your company
ldap phonebook>.<your company>.net
policyset.set1.p1.default.params.ldap.ldapconn.port=389
policyset.set1.p1.default.params.ldap.ldapconn.secureConn=false
These profiles come with ldap disabled by default. The String.Attributes parameter
tells CA which ldap attributes to retrieve from your company directory. For example,
if your company directory contains "uid" as an ldap attribute name, and you wish to
put it in the subject name of the certificate, then you need to have "uid" in the
ldapAttributes, and "$request.uid$ as one of teh components in the dnpattern.
iii. All three profiles come enabled by default. They can be
enabled/disabled either from the agent profile management or
from the .cfg flat file.
iv. After all the setup is done, restart the CMS CA from the
command line by typing
<ca-server-root>/cert-<id>/restart-cert.
1. For this example, make sure that the CMS TokenKey CA has been installed
before proceeding.
NOTE: For the purposes of this document, the <ca-server-root> and the
<tks-server-root> are the same <server-root>; the CMS Token Key
CA and CMS TokenKey TKS are merely two separate instances
under the same server root.
2. Use the Console to create an CMS TokenKey TKS instance of the
"Netscape Certificate Management System"
3. Follow the installation wizard to complete the configuration for this CMS
TokenKey TKS. Make sure to select the "Token Key Service Manager" in the
Subsystem panel when you go through the installation wizard.
4. After you finish configuring the CMS TokenKey TKS, you need to do the
following:
a. As an administrator, go to the administration console:
i. Add a special "agent" user on the CMS TokenKey TKS
(e. g. "TPS Trust Entity") - [Configuration] [Users and Groups]
[Users] [Add]. At "Edit User Information", enter all info
(phone number and email are optional), including full name
(e. g. "TPS Trust Entity").
ii. Still at the "Edit User Information", select the
"Token Key Service Manager Agents" group.
b. Assuming that you need to create the first MasterKey for the CMS
TokenKey TKS, then do the following:
i. Set LD_LIBRARY_PATH to point to <tks-server-root>/bin/cert/lib.
ii. From the command line, execute "cd <tks-server-root>/alias/".
iii. Determine whether you want to store the key on a software token,
or a hardware token, and follow the appropriate procedure in your
CMS TokenKey TKS installation:
a. If you want to store the key on a software token, follow the
procedure described in detail in step J.1.c.i.
b. If you want to store the key on a hardware token, follow the
procedure described in detail in step J.1.c.ii.
iv. Restart the CMS TokenKey TKS on the command line by typing
"<tks-server-root>/cert-<tks-id>/restart-cert".
The Token TPS package should be unpacked into an existing CMS installation's
server root. The location is
<server-root>/bin/cert/tps
The setup program for the TokenKey TPS is located in <server-root>/bin/cert/tps/setup/create.pl.
To execute the setup program:,
cd <server-root>/bin/cert/tps/setup
<server-root>/install/perl create.pl
For this example, follow Chapter 16 of the CMS Administration Guide to setup
cloning for any CMS TokenKey CMS subsystem (i. e. - CMS TokenKey CA and/or
CMS TokenKey TKS).
For this example, if you want to setup CMS TokenKey TPS failover, please perform
the following steps:
1. cd <nes-server-root>/tps/config/, and edit the CMS.cfg.
2. For the entry "conn.tks<n>.hostport" where <n> is the
corresponding CMS TokenKey TKS connection ID, put down all the available
hosts and agent ports (space-separated) in the following format:
conn.tks<n>.hostport=mytkshost.redhat.com:2000 yourtkshost.redhat.com:2001 histkshost.redhat.com:2002
Each host port grouping is separated by a white space.
3. For the entry "conn.ca<n>.hostport" where <n> is the
corresponding CMS TokenKey CA connection ID, put down all the available
hosts and CMS TokenKey EE SSL ports (space-separated) in the following
format:
conn.ca<n>.hostport=mycahost.redhat.com:2000 yourcahost.redhat.com:2001 hiscahost.redhat.com:2002
Each host port grouping is separated by a white space.
4. The number of tks host port groupings must be the same as the one for ca
host port groupings. In the above example, the number of tks host port
groupings is 3, and the number of ca host port groupings is also 3.
Get info from readme_esc.txt. Currently supported enrollment client is ESC;
supported browsers are Mozilla, Firefox; supported email client is Thunderbird.
An TokenKey token is installed with some default
keys that were generated by a master key that is shared
by the token manufacturer and the deployment site. For
this example, an CMS TokenKey token was utilized.
The Key Change Over is an operation where the CMS TokenKey
Backend replaces the default keys with the new keys
that are generated by a new and private master key
specific to the deployment site. The manufacturer will
not have access to this private master key.
To setup key change over, you need to perform two main tasks:
1. Create a new master key and setup version mapping in CMS TokenKey TKS:
a. Set LD_LIBRARY_PATH to point to <tks-server-root>/bin/cert/lib.
b. From the command line, execute "cd <tks-server-root>/alias/".
c. Determine whether you want to store the key on a software token,
or a hardware token, and follow the appropriate procedure in your
CMS TokenKey TKS installation:
i. If you want to store the key on a software token, execute
"../bin/cert/tools/tksTool -M -n <masterKeyId> -d . -p
<certPrefix>":
where <masterKeyId> is the unique name for the master key.
Make sure it is a unique value in the certificate database.
where <certPrefix> is the prefix for the CMS TokenKey TKS
certificate database. For example, if the name of the certificate
database is cert-tks-air-cert8.db, then the prefix is
cert-tks-air-.
After executing the above command, you will get the following
result:
Enter Password or Pin for "NSS Certificate DB":
Generating and storing the master key on the specified token . . .
Naming the master key "tks-masterkey" . . .
Computing and displaying KCV of the master key on the specified token . . .
tks-masterkey key KCV: 3339 0A69
Successfully generated, stored, and named the master key
including computing and displaying its KCV!
Next, add the following to the CMS.cfg located in
<tks-server-root>/cert-<tks-id>/config:
tks.mk_mappings.#02#01=internal:<masterKeyId>
Note that "#02" represents the master key version.
ii. If you want to store the key on a hardware token, execute
"../bin/cert/tools/tksTool -M -n <masterKeyId> -d . -p
<certPrefix> -h <tokenname>".
where <masterKeyId> is the unique name for the master key.
Make sure it is a unique value in the certificate database.
where <certPrefix> is the prefix for the CMS TokenKey TKS
certificate database. For example, if the name of the certificate
database is cert-tks-air-cert8.db, then the prefix is
cert-tks-air-.
where <tokenname> is the name of the hardware token
After executing the above command, you will get the following
result:
Enter Password or Pin for <tokenname>:
Generating and storing the master key on the specified token . . .
Naming the master key "tks-masterkey" . . .
Computing and displaying KCV of the master key on the specified token . . .
tks-masterkey key KCV: 0310 D87B
Successfully generated, stored, and named the master key
including computing and displaying its KCV!
Then, add the following to the CMS.cfg located in
<tks-server-root>/cert-<tks-id>/config:
tks.mk_mappings.#02#01=<tokenname>:<masterKeyId>
Note that "#02" represents the master key version.
d. Restart the CMS TokenKey TKS on the command line by typing
"<tks-server-root>/cert-<tks-id>/restart-cert".
2. Enable key change over in the CMS TokenKey TPS:
a. To enable key change over in the CMS TokenKey TPS, both the token type(s)
as well as the operation(s) must be determined in the CMS.cfg. For this
example, a key change over request will be provided for the CMS TokenKey
token type for the enrollment and format operations. Additionally,
it is assumed that the CMS TokenKey token being used contains an applet
version with a major version number of 1 (e. g. - 404E4697.ijc, or
4122DFB4.ijc).
This is determined in the Default Operations section:
i. Each type of operation contains a parameter called
"op.<op>.mapping.order" containing one or more
mapping IDs.
NOTE: If the "op.<op>.mapping.order" parameter contains more
than one mapping ID, then each mapping ID is processed in
sequential order until a target is determined, or else an
error is returned. If the "op.<op>.mapping.order"
parameter is missing, or not set in the CMS.cfg, then the code
will return an error.
ii. Each mapping ID references a series of parameters associated
with the requested operation called "filters".
NOTE: Each "filter" may contain a specific value for the request
to be tested against. Empty or missing "filters" equate to
a "wildcard" rule which allows the request to contain any
value, and are thus inherently "true".
iii. If the request passes each "filter" (basically, all "filters"
for a given operation are "AND"ed together to form a decision),
then the specified target operation is processed.
Thus, for this example, the following token operations will be targeted
after passing their associated filters (please note that the comment's
reference to the pinReset operation is not applicable to this
CMS TokenKey example):
#########################################
# Default Operations
#
# op.<op>.mapping.order=<n>,<n>,<n>
# - contains at least one value or a series
# of comma-separated mapping values which
# are checked in sequential order
# op.<op>.mapping.<n>.filter.tokenType=userKey
# - can be either empty or token type
# specified by the client
# op.<op>.mapping.<n>.filter.tokenATR=
# - can be either empty or token ATR
# specified by the client
# op.<op>.mapping.<n>.filter.appletMajorVersion=1
# - can be either empty or applet major version
# specified by the client
# op.<op>.mapping.<n>.filter.appletMinorVersion=
# - can be either empty or applet minor version
# specified by the client
# op.<op>.mapping.<n>.target.tokenType=userKey
# - if tokenType, tokenATR, appletMajorVersion,
# and appletMinorVersion are matched, value in
# targetTokenType will be used to locate
# the corresponding token profile to
# process the request.
#
# where
# <op> - operation; enroll,pinReset,format
# <n> - mapping ID; order is specifiable
#
# Token ATR:
# Web Store - 3B759400006202020201
#########################################
op.enroll.mapping.order=0,1,2
.
.
.
op.enroll.mapping.1.filter.tokenType=deviceKey
op.enroll.mapping.1.filter.tokenATR=
op.enroll.mapping.1.filter.tokenCUID.begin=
op.enroll.mapping.1.filter.tokenCUID.end=
op.enroll.mapping.1.filter.appletMajorVersion=1
op.enroll.mapping.1.filter.appletMinorVersion=
op.enroll.mapping.1.target.tokenType=deviceKey
.
.
.
op.format.mapping.order=0
op.format.mapping.0.filter.tokenType=
op.format.mapping.0.filter.tokenATR=
op.format.mapping.0.filter.tokenCUID.begin=
op.format.mapping.0.filter.tokenCUID.end=
op.format.mapping.0.filter.appletMajorVersion=
op.format.mapping.0.filter.appletMinorVersion=
op.format.mapping.0.target.tokenType=userKey
NOTE: The actual target utilized for the key change over during
the enrollment operation for the CMS TokenKey token request
will be "op.enroll.mapping.1.target.tokenType=deviceKey" since
this is the first complete set of mapping ID filters that will
be passed by this request. Although another mapping ID exists,
it will not be processed unless the specified order is changed
in the "op.enroll.mapping.order" parameter. For more detailed
information regarding a specific applet, including its
associated major and minor version numbers, refer to the
"readme.txt" file located in the "applets" directory.
b. To enable key change over for CMS TokenKey Enrollment in the
CMS TokenKey TPS, the following lines must be present in the CMS.cfg:
#########################################
# Enrollment Operation For CMS TokenKey
#########################################
.
.
.
op.enroll.houseKey.update.symmetricKeys.enable=false
op.enroll.houseKey.update.symmetricKeys.requiredVersion=1
For this example, change these parameters to contain the
following values:
op.enroll.houseKey.update.symmetricKeys.enable=true
op.enroll.houseKey.update.symmetricKeys.requiredVersion=2
NOTE: If the "op.enroll.houseKey.update.symmetricKeys.enable"
parameter is missing, or not set in the CMS.cfg, then the
code assumes the value of this parameter to be false.
c. To enable key change over for CMS TokenKey Format in the CMS TokenKey TPS,
the following lines must be present in the CMS.cfg:
#########################################
# Format Operation For tokenKey
#
# - applicable to userKey
# - applicable to CMS TokenKey
# - applicable to CMS TokenKey with Legacy Applet
#########################################
.
.
.
op.format.tokenKey.update.symmetricKeys.enable=false
op.format.tokenKey.update.symmetricKeys.requiredVersion=1
For this example, change these parameters to contain the
following values:
op.format.tokenKey.update.symmetricKeys.enable=true
op.format.tokenKey.update.symmetricKeys.requiredVersion=2
NOTE: If the "op.format.tokenKey.update.symmetricKeys.enable"
parameter is missing, or not set in the CMS.cfg, then the
code assumes the value of this parameter to be false.
d. Stop the https server by running
<nes-server-root>/https-<id>/stop.
e. Start the https server by running
<nes-server-root>/https-<id>/start.
f. Once this is configured, the CMS TokenKey TPS will automatically update
the keys on an CMS TokenKey token when performing either an enrollment
operation or a format operation if the key version is not equal to 2.
Perform a new enrollment from esc using an CMS TokenKey token to
check out this feature.
NOTE: The CMS TokenKey TPS audit log contains information denoting
whether or not the key changeover worked successfully.
1. To setup the applet update feature in the CMS TokenKey TPS, both the token
type(s) as well as the operation(s) must be determined in the CMS.cfg.
Applet update operations may perform either an applet upgrade
(moving from no applet to any applet, or an older applet to a newer applet),
or an applet downgrade (moving from a newer applet to an
older applet).
For this example, an applet upgrade will be performed on
an CMS TokenKey token for the enrollment and format operations. Therefore,
it will be assumed that the CMS TokenKey token being used either contains
no applets, or contains an applet version with version number
that is prior to the requiredVersion number.
This is determined in the Default Operations section:
a. Each type of operation contains a parameter called
"op.<op>.mapping.order" containing one or more
mapping IDs.
NOTE: If the "op.<op>.mapping.order" parameter contains more
than one mapping ID, then each mapping ID is processed in
sequential order until a target is determined, or else an
error is returned. If the "op.<op>.mapping.order"
parameter is missing, or not set in the CMS.cfg, then the code
will return an error.
b. Each mapping ID references a series of parameters associated
with the requested operation called "filters".
NOTE: Each "filter" may contain a specific value for the request
to be tested against. Empty or missing "filters" equate to
a "wildcard" rule which allows the request to contain any
value, and are thus inherently "true".
c. If the request passes each "filter" (basically, all "filters"
for a given operation are "AND"ed together to form a decision),
then the specified target operation is processed.
Thus, for this example, the following token operations will be targeted
after passing their associated filters (please note that the comment's
reference to the pinReset operation is not applicable to this
CMS TokenKey example):
#########################################
# Default Operations
#
# op.<op>.mapping.order=<n>,<n>,<n>
# - contains at least one value or a series
# of comma-separated mapping values which
# are checked in sequential order
# op.<op>.mapping.<n>.filter.tokenType=userKey
# - can be either empty or token type
# specified by the client
# op.<op>.mapping.<n>.filter.tokenATR=
# - can be either empty or token ATR
# specified by the client
# op.<op>.mapping.<n>.filter.appletMajorVersion=1
# - can be either empty or applet major version
# specified by the client
# op.<op>.mapping.<n>.filter.appletMinorVersion=
# - can be either empty or applet minor version
# specified by the client
# op.<op>.mapping.<n>.target.tokenType=userKey
# - if tokenType, tokenATR, appletMajorVersion,
# and appletMinorVersion are matched, value in
# targetTokenType will be used to locate
# the corresponding token profile to
# process the request.
#
# where
# <op> - operation; enroll,pinReset,format
# <n> - mapping ID; order is specifiable
#
# Token ATR:
# Web Store - 3B759400006202020201
#########################################
op.enroll.mapping.order=0,1,2
.
.
.
op.enroll.mapping.2.filter.tokenType=
op.enroll.mapping.2.filter.tokenATR=
op.enroll.mapping.2.filter.tokenCUID.begin=
op.enroll.mapping.2.filter.tokenCUID.end=
op.enroll.mapping.2.filter.appletMajorVersion=
op.enroll.mapping.2.filter.appletMinorVersion=
op.enroll.mapping.2.target.tokenType=userKey
.
.
.
op.format.mapping.order=0
op.format.mapping.0.filter.tokenType=
op.format.mapping.0.filter.tokenATR=
op.format.mapping.0.filter.tokenCUID.begin=
op.format.mapping.0.filter.tokenCUID.end=
op.format.mapping.0.filter.appletMajorVersion=
op.format.mapping.0.filter.appletMinorVersion=
op.format.mapping.0.target.tokenType=tokenKey
NOTE: In this example, the filter called
"op.enroll.mapping.1.filter.appletMajorVersion=1" will fail,
since the CMS TokenKey token being utilized either contains no
applet, or an applet containing a major version number of 0.
Therefore, the actual target utilized for the applet update
during the enrollment operation for the CMS TokenKey token
request will be "op.enroll.mapping.2.target.tokenType=userKey"
since this is the first complete set of mapping ID filters that
will be passed by this request. For more detailed information
regarding a specific applet, including its associated major
and minor version numbers, refer to the "readme.txt" file
located in the "applets" directory.
2. To allow an applet to be copied to an CMS TokenKey token which does not
initially contain an applet, the following line must be present in
the CMS.cfg during CMS TokenKey Enrollment in the CMS TokenKey TPS:
#########################################
# Enrollment Operation For CMS TokenKey with Legacy Applet
#########################################
.
.
.
op.enroll.userKey.update.applet.emptyToken.enable=false
For this example, change this parameter to contain the following value:
op.enroll.userKey.update.applet.emptyToken.enable=true
NOTE: If this parameter is missing, or not set in the CMS.cfg, then the
code assumes the value of this parameter to be false.
3. To enable all other applet updates for CMS TokenKey Enrollment in the
CMS TokenKey TPS, the following lines must be present in the CMS.cfg:
#########################################
# Enrollment Operation For CMS TokenKey with Legacy Applet
#########################################
.
.
.
op.enroll.userKey.update.applet.enable=false
op.enroll.userKey.update.applet.requiredVersion=1.2.416DA155.ijc
op.enroll.userKey.update.applet.directory=<...>
For this example, change these parameters to contain the following values:
op.enroll.userKey.update.applet.enable=true
op.enroll.userKey.update.applet.requiredVersion=1.2.416DA155.ijc
op.enroll.userKey.update.applet.directory=<nes-server-root>/tps/applets
NOTE: For the value associated with the
"op.enroll.userKey.update.applet.requiredVersion" parameter,
a file by this name with the extension ".ijc" must be present
in the directory specified by the value associated with the
"op.enroll.userKey.update.applet.directory" parameter.
Further, if the file name value associated with the
"op.enroll.userKey.update.applet.requiredVersion" parameter
contains ANY alphabetic characters, then ALL of these alphabetic
characters MUST ALWAYS be uppercase letters; this applies to the
actual name of the file, as well as to the value of the
"op.update.userKey.applet.requiredVersion" parameter.
If the "op.enroll.userKey.update.applet.enable" parameter is
missing, or not set in the CMS.cfg, then the code assumes the
value of this parameter to be false.
4. To allow an applet to be copied to an CMS TokenKey token which does not
initially contain an applet, the following line must be present in
the CMS.cfg during CMS TokenKey Format in the CMS TokenKey TPS:
#########################################
# Format Operation For tokenKey
#
# - applicable to userKey
# - applicable to CMS TokenKey
# - applicable to CMS TokenKey with Legacy Applet
#########################################
.
.
.
op.format.tokenKey.update.applet.emptyToken.enable=false
For this example, change this parameter to contain the following value:
op.format.tokenKey.update.applet.emptyToken.enable=true
NOTE: If this parameter is missing, or not set in the CMS.cfg, then the
code assumes the value of this parameter to be false.
5. To enable all other applet updates for CMS TokenKey Format in the
CMS TokenKey TPS, the following lines must be present in the CMS.cfg:
#########################################
# Format Operation For tokenKey
#
# - applicable to userKey
# - applicable to CMS TokenKey
# - applicable to CMS TokenKey with Legacy Applet
#########################################
.
.
.
op.format.tokenKey.update.applet.enable=false
op.format.tokenKey.update.applet.requiredVersion=1.2.416DA155.ijc
op.format.tokenKey.update.applet.directory=<...>
For this example, change these parameters to contain the following values:
op.format.tokenKey.update.applet.enable=true
op.format.tokenKey.update.applet.requiredVersion=1.2.416DA155.ijc
op.format.tokenKey.update.applet.directory=<nes-server-root>/tps/applets
NOTE: For the value associated with the
"op.format.tokenKey.update.applet.requiredVersion" parameter,
a file by this name with the extension ".ijc" must be present
in the directory specified by the value associated with the
"op.format.tokenKey.update.applet.directory" parameter.
Further, if the file name value associated with the
"op.format.tokenKey.update.applet.requiredVersion" parameter
contains ANY alphabetic characters, then ALL of these alphabetic
characters MUST ALWAYS be uppercase letters; this applies to the
actual name of the file, as well as to the value of the
"op.update.tokenKey.applet.requiredVersion" parameter.
If the "op.format.tokenKey.update.applet.enable" parameter is
missing, or not set in the CMS.cfg, then the code assumes the
value of this parameter to be false.
6. Furthermore, if it is desired to enable encryption for ALL operation
commands sent to the token, set the following additional parameter in
the CMS.cfg:
#########################################
# channel.encryption:
#
# - enable encryption for all operation commands to token
# - default is true
#########################################
channel.encryption=true
NOTE: If this parameter is missing, or not set in the CMS.cfg, then the
code assumes the value of this parameter to be true.
7. Additionally, further granularity for applet update by the CMS TokenKey
Enrollment Operation may be specified using the following parameter
in the CMS.cfg:
#########################################
# Enrollment Operation For CMS TokenKey with Legacy Applet
#########################################
.
.
.
op.enroll.userKey.update.applet.encryption=true
NOTE: The true/false value associated with the
"op.enroll.userKey.update.applet.encryption" parameter is
applied to all applet updates, and always overrides any value set
by the value of the "channel.encryption" parameter as it applies
to applet updates. By default, if NEITHER the "channel.encryption"
parameter NOR the "op.enroll.userKey.update.applet.encryption"
parameter are set to be true, then applet updates performed by
deviceKey Enrollment Operations are merely MACed. If this parameter
is missing, or not set in the CMS.cfg, then the code assumes the
value of this parameter to be true.
8. Likewise, further granularity for applet update by the CMS TokenKey
Format Operation may be specified using the following parameter
in the CMS.cfg:
#########################################
# Format Operation For tokenKey
#
# - applicable to userKey
# - applicable to CMS TokenKey
# - applicable to CMS TokenKey with Legacy Applet
#########################################
.
.
.
op.format.tokenKey.update.applet.encryption=true
NOTE: The true/false value associated with the
"op.format.tokenKey.update.applet.encryption" parameter is applied
to all applet updates, and always overrides any value set by the
value of the "channel.encryption" parameter as it applies to applet
updates. By default, if NEITHER the "channel.encryption" parameter
NOR the "op.format.tokenKey.update.applet.encryption" parameter are
set to be true, then applet updates performed by CMS TokenKey Format
Operations are merely MACed. If this parameter is missing, or not
set in the CMS.cfg, then the code assumes the value of this parameter
to be true.
9. Stop the https server by running
<nes-server-root>/https-<id>/stop.
10. Start the https server by running
<nes-server-root>/https-<id>/start.
11. The CMS TokenKey TPS queries the applet version from the client before
the execution of any operations such as enrollment and format.
If the update feature is enabled, and the applet version from the client
is different from the one that is specified by this
'op.<operation>.<token type>.update.applet.requiredVersion'
parameter, the CMS TokenKey TPS will update the applet automatically.
Perform a new enrollment from esc a deviceKey token to
check out this feature.
NOTE: The CMS TokenKey TPS audit log contains information denoting whether
or not the applet update worked successfully.
|
|