| Sun Crypto Accelerator 6000 Board User’s Guide for Version 1.1 |    
|
| Sun Crypto Accelerator 6000 Board User’s Guide for Version 1.1 |
|
| C H A P T E R 3 |
Administering the Sun Crypto Accelerator 6000 Board |
This chapter provides an overview of administering the board on both Oracle Solaris and Linux platforms with the scamgr and scadiag utilities, and the scad and scakiod service daemons. Additional instructions for Linux platforms are included in the last section. The chapter contains the following sections:
The scamgr utility offers a command-line interface to the Sun Crypto Accelerator 6000 Board that can be accessed remotely. Only users designated as device or keystore security officers are permitted to use the scamgr utility. When you first connect to a board with scamgr, you are prompted to create an initial device security officer and password.
There are two types of security officers, device security officers (DSOs) and keystore security officers (KSOs). The first DSO is created when the board is initialized. The first KSO is created when the first keystore is created. DSOs can create other DSO accounts and KSOs can create other KSO accounts. The default behavior for scamgr is to log in as a KSO. To log in as a DSO, you must sun scamgr with the -D command line option. If you have already started an scamgr session but are logged out from all devices, you can use the connect command with the dso keyword to log in as a DSO (see TABLE 3-1).
| Note - KSOs can make changes to keystores only. DSOs can make changes global to the board. |
DSOs configure the physical board and can affect keystores globally. DSO capabilities include, but are not limited to the following:
KSOs use a set of commands that pertain only to a single instance of a keystore. KSO capabilities include:
The scamgr command-line syntax is:
| Note - When using the -d option, mcaN is the board’s device name, where N corresponds to the Sun Crypto Accelerator 6000 device instance number. |
TABLE 3-1 shows the options for the scamgr utility.
| Note - The variable sec-officer is used throughout this document as an example security officer name. |
See Authentication and Logging In and Out With scamgr for more information.
scamgr can run in one of three modes. These modes differ mainly in how commands are passed into scamgr. The three modes are Single-Command mode, File mode, and Interactive mode.
| Note - To use scamgr, you must authenticate as security officer. How often you need to authenticate as security officer is determined by which operating mode you are using. |
In Interactive mode, you must authenticate as security officer every time you connect to a board. This is the default operating mode for scamgr, and is initiated by not specifying filename or any parameters when starting scamgr. To log out of scamgr in Interactive mode, use the logout command. Refer to Authentication and Logging In and Out With scamgr.
Interactive mode presents the user with an interface similar to ftp(1), where commands can be entered one at a time. The -y option is not supported in Interactive mode. Security officers must answer all confirmation questions.
In Single-Command mode, you must authenticate as security officer for every command. Once the command is executed, you are logged out of scamgr.
When entering commands in Single-Command mode, you specify the command to be run after all the command-line switches are specified. For example, in Single-Command mode, the following command would show all the users in a given keystore and return the user to the command shell prompt.
All output from Single-Command mode goes to the standard output stream. This output can be redirected using standard UNIX shell-based methods.
In File mode, you must authenticate as security officer for every file you run. You are logged out of scamgr after the commands in the command file are executed.
To enter commands in File mode, you specify a file from which scamgr reads one or more commands. The file must be ASCII text, consisting of one command per line. Begin each comment with a hash (#) character. If the File mode option is set, scamgr ignores any command-line arguments after the last option. The following example runs the commands in the deluser.scr file and answers all prompts in the affirmative:
The scamgr utility establishes an encrypted network connection (channel) between the scamgr application and the Sun Crypto Accelerator 6000 firmware running on a specific board. This point-to-point encrypted channel is not visible to any of the other software components between scamgr and the device (for example, the mca device driver). This encrypted channel allows scamgr to run safely and securely over the network. The key exchange is performed with RSA 1024-bit keys while the bulk data is protected using AES-128. SHA1 HMACs provide data integrity for each command data payload.
During setup of the encrypted channel, boards identify themselves by their hardware serial ID address and an RSA public key. A trust database ($HOME/.sunw/sca/trustdb) is created the first time scamgr connects to a board. This file contains all of the boards that are currently trusted by the security officer.
When the firmware gives scamgr an RSA public key, a SHA-1 hash is taken on the modulus. This action forms a key fingerprint that can be stored in a database in the UNIX user's home directory. When a connection is made and an unrecognized key is given to scamgr by the firmware, scamgr prompts the security officer to either abort the connection, accept the key for this one session, or accept the key permanently as a trusted key in the trust database. If a key to a previously trusted card changes, scamgr offers the same choices except that when accepting the key as a trusted key it overwrites the old key with the new one.
The first step in configuring a Sun Crypto Accelerator 6000 Board is to initialize it. There are two types of initialization. The first is board initialization and the second is keystore initialization. When you first connect to an uninitialized board with scamgr, you are prompted to perform a board initialization, which creates a device security officer (DSO) account. Once the board is initialized, you are prompted to perform a keystore initiailiztion, which creates a keystore security officer (KSO) account. For more information on DSOs and KSO, see Device and Keystore Security Officers.
Board initialization occurs only when the board is uninitialized. Board initialization enables the administrator to select whether the board (and all its keystores) will run in FIPS mode or not, and creates the first DSO. DSOs can perform tasks that affect the board as a whole, such as firmware upgrades and board zerioization. No keystores can be created until the board itself has been initialized. To log in as a DSO, you must start scamgr with the -D or dso option.
Board initialization is secured using a factory key, which is an RSA key that is permanently stored in the hardware. This key is only used to secure communications to an uninitialized board. After any successful board initialization, a new remote access key is created. This new key is used to secure communications when new keystores are initialized and administered.
|
1. Select FIPS 140-2 mode or non-FIPS mode.
When in FIPS mode the board is FIPS 140-2, level 3 compliant. FIPS 140-2 is a Federal Information Processing Standard that requires tamper-resistance and a high level of data integrity and security. Refer to the FIPS 140-2 document located at:
http://www.nist.gov
2. Create an initial DSO name and password.
See Naming Requirements.
Initial Security Officer Name: device-sec-officer Initial Security Officer Password: Confirm Password: |
3. Verify the configuration information:
Once the board is initialized, connecting to it with scamgr displays a menu of any existing keystores, and also allows the keystore security officer (KSO) to create a new keystore. For details on keystores, see Web Server Concepts and Terminology. Keystore creation creates the first KSO. The KSO then creates the name of the keystore and decides whether the keystore is local or cenralized (see Perform a Keystore Initialization and Use an Existing Keystore).
In addition, a keystore can be restored to an initialized board by loading it from a backup (see Perform a Keystore Initialization and Use an Existing Keystore). The scamgr utility prompts for the backup file location and uploads the file to the board as part of the keystore initialization process. This option can be used to recover a keystore when a board or host system is damaged, or to configure a second Sun Crypto Accelerator 6000 board work with an existing keystore in a fault-tolerant architecture.
Use this procedure when you are initializing the board for the first time, or when you do not want to initialize an existing keystore.
1. Connect to the board with the scamgr command.
2. Enter 2 then 1 as shown in the following example:
See Naming Requirements.
If you are adding multiple boards to a single keystore, you might want to initialize all of the boards to use the same keystore information. In addition, you might want to restore a Sun Crypto Accelerator 6000 Board to the original keystore configuration. This section describes how to initialize a board to use an existing keystore that is stored in a backup file.
You must first create a backup file of an existing board configuration before performing this procedure. Creating and restoring a backup file requires a password to encrypt and decrypt the data in the backup file. (See Back Up a Master Key.)
|
|
1. Initialize the board with the scamgr command.
2. Enter 2 as shown in the following example:
3. Enter the path and password to the backup file:
| Note - If the backup file was created in Multi-Admin mode, authentication is required by multiple security officers assigned the Multi-Admin role. |
4. Verify the configuration information.
Only security officers can log into a Sun Crypto Accelerator 6000 board with this utility. It is not possible to log into a user account using scamgr. User accounts are for applications that use the card (for example, with the PKCS#11 interface).
In accordance with FIPS 140-2 guidelines, no security officer can issue commands without first authenticating. Authentication is identity-based. A valid security officer name and password must exist in the card's keystore before access is granted.
When you use scamgr from the command line and specify host, port, and device using the -h, -p, and -d options respectively, you are immediately prompted to log in as security officer if a successful network connection was made. See scamgr Syntax and scamgr Options for more information.
The scamgr prompt in Interactive mode is displayed as follows:
The following table defines the variables in the scamgr prompt:
|
1. Abort this connection 2. Trust the board for this session only 3. Trust the board for all future sessions |
|
| Note - The remaining examples in this chapter were created with the Interactive mode of scamgr. |
When connecting to a new board, scamgr must create a new entry in the trust database.
|
When connecting to a board that has a changed remote access key, you must use scamgr to change the entry corresponding to the board in the trust database.
|
If you are working in Interactive mode, you might want to disconnect from one board and connect to another board without completely exiting scamgr.
|
scamgr{mcaN@hostname, sec-officer}> logout scamgr> connect host hostname dev mca2 Security Officer Login: sec-officer Security Officer Password: scamgr{mca2@hostname, sec-officer}> |
In the previous example, notice that the scamgr> prompt no longer displays the device instance number, hostname, or security officer name. To log into another device, type the connect command with the following optional parameters.
scamgr does not allow you to issue the connect command if you are already connected to a Sun Crypto Accelerator 6000 Board. You must first log out and then issue the connect command.
Each new connection causes scamgr and the target Sun Crypto Accelerator 6000 firmware to renegotiate new session keys to protect the administrative data that is sent.
Use one of the following actions to quit the scamgr utility.
Take one of the following actions:
This section lists the available scamgr commands and describes their usage.
The scamgr utility has a command language that must be used to interact with the Sun Crypto Accelerator 6000 Board. You enter commands using all or part of a command (enough to uniquely identify that command from any other command). Entering sh instead of show would work, but re is ambiguous because it could be reset or rekey.
The following example shows entering commands using entire words:
scamgr{mcaN@hostname, sec-officer}> show user User Status ----------------------------------------------------- web-admin Enabled Tom Enabled ----------------------------------------------------- |
The same information can be obtained in the previous example using partial words as commands, such as sh us.
An ambiguous command produces an explanatory response:
TABLE 3-4 lists the scamgr commands.
|
(DSO only) Backs up the master key and device configuration to the path specified by pathname. If no path is specified scamgr prompts the user for the pathname. Any successful backup increments the backup counter by one (see show status). If Multi-Admin mode is enabled when this command is entered it requires authentication by multiple security officers with the Multi-Admin role. |
|
|
(KSO only) Performs a full keystore backup including all user and key objects, log messages, and the master key and keystore configuration. These are collected, encrypted and placed in the file referenced by pathname. If no path is specified, scamgr prompts for one. Successful backups increment the backup counter by one (see show status). If Multi-Admin mode is enabled when this command is entered, it requires authentication by multiple security officers with the Multi-Admin role. |
|
|
(KSO only) Backs up the master key only, encrypting it and placing it in the file specified by pathname. This backup file can be used to import the master key into one or more other boards so they can make use of the same keystore. |
|
|
connect host hostname port portnumber dev mcaN keystore keystorename dso |
Attempts to establish a connection to a Sun Crypto Accelerator board. If the host option is specified, it must be followed by a valid host name or IP address. If the port option is specified, it must be followed by a valid port number. If the dev option is specified, it must be followed by a valid device instance number (followed by the mca string). If the keystore option is specified, it must be a full or partial keystore name. The dso option logs in as a device security officer rather than a keystore security officer. The default values for these arguments are the same as for the -h, -p, -d, and -k options (see TABLE 3-1). |
|
(KSO only) Converts a keystore from a local keystore to a centralized one or vice-versa, depending on the current keystore type. |
|
|
(KSO only) Copies the existing keystore (including all users, security officers, and key objects) to a new keystore named newkeystorename. |
|
|
Creates the named security officer. If the security officer name is not specified in sec-officer, scamgr prompts for one. Valid names must begin with an alphabetical character and be between 1 and 63 characters. Valid characters consist of alphanumeric characters and the hyphen (-), underscore (_), and period (.) characters. When creating a new security officer the current security officer will be asked to set the new security officer's password and then asked to confirm it. |
|
|
(KSO only) Creates a user named username. If username is not specified, scamgr prompts for one. The name restrictions are identical to those in the create so command. When creating a user, the security officer is asked to set the new user's password, then asked to confirm it. |
|
|
(KSO only) Ensure that you create a full keystore backup if you want to be able to restore a keystore before deleting it (see the backup keystore command). This command deletes a keystore from an existing board. The master key and configuration are deleted, along with the keystore database. The only way to restore a keystore once it has been deleted is to restore it from a full keystore backup. |
|
|
Deletes the master key named keystorename from the board. This will not remove any key database files or entries. Only the master key from the board on which the command is run is removed. |
|
|
Deletes the security officer named sec-officer from the keystore. Confirmation is requested unless the -y option is entered when scamgr is executed. If the board is in Multi-Admin mode and the security officer to be deleted also has the Multi-Admin role, the security officer cannot be removed. The security officer must first be removed from the Multi-Admin role and then deleted (see the disable authmember command). |
|
|
(KSO only) Deletes the user named username from the keystore. All key material owned by the user is also deleted. Confirmation is requested unless the -y option is supplied when scamgr is started. |
|
|
Performs firmware diagnostics on the board. This command tests the general hardware and cryptographic subsystems. This command returns a PASS value for each passing subsystem. If a subsystem fails, this command attempts to identify the specific failure. Tests that normally follow a failed test do not occur. |
|
|
Removes the Multi-Admin role from the security officer sec-officer. If this command is entered when Multi-Admin mode is enabled, it requires authentication by multiple security officers with the Multi-Admin role assigned. This command does not execute if the command would reduce the required minimum numbers of security officers with the Multi-Admin role. |
|
|
(KSO only) Prevents users and kernel consumers from using the keystore named keystorename. The keystore being disabled must be locked for this command to execute correctly. |
|
|
Takes the board out of Multi-Admin mode. This command requires authentication by multiple security officers with the Multi-Admin role. |
|
|
(DSO only) Disables keystore creation functions on the board. With this setting disabled, no new keystores can be created. |
|
|
(KSO only) Disable the user named username in the keystore. A disabled user cannot log in and cannot access key material. |
|
|
Gives the security officer named sec-officer the Multi-Admin role. If this command is entered while Multi-Admin mode is enabled, it requires authentication by multiple security officers with the Multi-Admin role. |
|
|
(KSO only) Enables a keystore for use by users and kernel consumers. This command can only be executed on a locked keystore. When a locked keystore is enabled, it remains enabled only until the next reset. |
|
|
Enables Multi-Admin mode. When enabled, certain commands require multiple security officers to authenticate before the command can complete successfully. When this command is executed, the security officer is presented with the current Multi- Admin mode settings and is given the opportunity to change these values before the command completes. This command does not identify the -y option. |
|
|
(DSO only) Enables new keystores to be created on the board. Keystore creation is enabled by default. |
|
|
(DSO only) Loads a firmware image specified in firmwarepath to the board. Firmware images must be digitally-signed code from Sun. When new firmware is successfully uploaded, the device continues to run the current firmware until it is manually reset (see the reset command). |
|
|
(KSO only) Locks the keystore (keystorename) which prevents the keystore from being used until it is enabled (see the enable keystorename command). Keystores that are locked are disabled by default. Once the keystore is enabled, it stays enabled until the board is reset either explicitly or through a power cycle. A keystore can be unlocked which turns off this default disable behavior (see the unlock keystorename command). If this command is entered while Multi-Admin mode is enabled, it requires authentication by a quorum of security officers with the Multi-Admin role. |
|
|
Locks the master key. Once locked, the master key cannot be backed up using the backup master-key command. If the master key lock is set, new master keys created through the rekey command are automatically locked and cannot be backed up. Once set, a locked master key cannot be unset. If the master key is locked by a DSO, a board zeroize is required to clear it. If it is locked by a KSO, the lock cannot be cleared without deleting the keystore itself. Systems that use multiple boards on a single keystore should use this command with care, understanding that the need to rekey the master key is tantamount to needing to reinitialize all boards using that keystore on the system. For single-board systems, this command can be used more freely with the rekey command, with the understanding that recoverability of the data in the keystore is completely lost once a rekey happens. |
|
|
Discards the current authentication credentials and closes the connection to the device. This will not end the execution of scamgr. The only command that can be executed when not logged into a board is the connect command. |
|
|
(KSO only) Generates a new master key for the keystore. Keystore files are automatically re-encrypted in the new master key. Other boards working with the same keystore need to have this new master key loaded to be able to continue working with this keystore (see the zeroize command and the section on initialization). |
|
|
(DSO only) Rekeys the remote access key. This command logs the security officer out of the existing session when successful. |
|
|
(DSO only) Resets the board. This command logs the security officer out from the board and closes the session. |
|
|
(KSO only) Sets the keystore audit log level. The log level is an integer value from zero to seven, with each successive log level being incremented. The description of the log levels are as follows:
|
|
|
This command is deprecated. Please use the lock master-key command instead. |
|
|
set multiadmin minauth number-of-minimum-admin-role-sec-officers |
This command sets the quorum of security officers required for the successful completion of a Multi-Admin mode command. This value must be at least 2 and less than or equal to the total number of security officers on the system. In addition, if Multi-Admin mode is already enabled, the new value cannot exceed the number of security officers in the Multi-Admin role. If the board is in Multi-Admin mode then the command will require authentication by multiple security officers with the Multi-Admin role. |
|
Changes the timeout for commands requiring Multi-Admin mode authentication. This value is in minutes and must be between 1 and 1440 (1 day). If a value larger than 1440 is specified, the value will be set to 1440. If the board is already in Multi-Admin mode, it requires authentication by multiple security officers with the Multi-Admin role. |
|
|
Changes the password for the currently logged in security officer. To change passwords for keystore users, the PKCS#11 interface must be used. See Appendix E. |
|
|
Changes the password requirement setting. There are three levels of password requirements:
The system defaults to the Low security level when not in FIPS 140-2 mode and defaults to Med security level when in FIPS 140-2 mode. In FIPS mode, the board cannot be set below the Med security level. |
|
|
Changes the connection timeout value for administrative sessions. This parameter takes a value between 1 and 1440 as the number of minutes before the firmware will drop the authentication credentials of the logged in security officer and drop the connection. Values less than 1 disable the timeout completely. Values greater than 1440 minutes (1 day) are shortened to 1440. |
|
|
(KSO only) Displays the current keystore audit log. Audit logs are displayed to standard out by default, but can be sent to the file outfile using the path option keyword. The number of log messages displayed can be controlled with the range option, with the input value (logrange) being either a positive or negative integer that displays the log range of newest or oldest log entries, respectively. By default the entire log is displayed. |
|
|
(DSO only) Displays all the domains that have keystores loaded onto a given board. |
|
|
(DSO only) Lists all the keystores that a given board has master keys for. It also displays the type of keystore it is: centralized, local, or disconnected. A disconnected keystore is one where the master key is loaded but the actual key database is unavailable for some reason. Also, the domain that the keystore exists in is shown. |
|
|
(KSO only) Behaves identically to the show audit-log command, except that it works on the set of audit logs that have been rotated into the old audit log pool. For more details on controlling the size of the audit logs, see the man page for scakiod(1M). |
|
|
Shows all security officer accounts set for the keystore and whether they have the Multi-Admin role. |
|
|
Shows device and keystore parameters. The information is broken down into categories: version information, keystore information, and security settings. |
|
|
(KSO only) Shows all user accounts created in the keystore, and whether the users are enabled or disabled. |
|
|
(KSO only) Unlocks a locked keystore (see the lock keystorename command for details on locked keystores). This command requires a quorum of security officers with the Multi-Admin role to authenticate if Multi-Admin mode is enabled. |
|
|
(DSO only) Cleans the board of all security parameters, and returns the board to its uninitialized factory state. The board uses the factory remote access key to secure any connections to it while in the uninitialized state. Firmware upgrades done to the board prior to the zeroize command are preserved. Zeroizing a board does not delete the keystore file on the disk. Zeroizing a board without backing up its master key makes all data in the keystore that board was working with unrecoverable. |
scamgr has built-in help functions. To get help, you must enter a question mark (?) character following the command you want more help on. If you enter an entire command and a “?” exists anywhere on the line, you get the syntax for the command, for example:
You can also enter a question mark at the scamgr prompt to see a list of all of the scamgr commands and their description, for example:
| Note - You must log in to scamgr as a keystore security officer (KSO) to manage keystores as described in this section. Device security officers (DSOs) cannot perform the procedures in this section. For information on KSOs and DSOs, see Device and Keystore Security Officers. |
A keystore is a repository for key material. Associated with a keystore are keystore security officers (KSOs) and users. Keystores not only provide storage, but a means for key objects to be owned by user accounts. This situation enables keys to be hidden from applications that do not authenticate as the owner. Keystores have three components:
The scamgr utility supports multiple keystores running on a single board. Keystores must be uniquely named. Each individual keystore contains its own set of security officers, users, and key objects.
FIGURE 3-1 Multiple Keystore Support
At connection time, scamgr displays a list of keystores that can be logged into. Security officers can specify a keystore by name using the -k keystorename option. See TABLE 3-1.
| Note - Multiple boards can be configured to collectively work with the same keystore to provide additional performance and fault tolerance. |
Security officer names, user names, and keystore names must meet the following requirements:
|
63 characters for security officer names and user names.
|
|
Password requirements vary based on the current set passreq setting (low,
med, or high).
This command sets the password character requirements for any password prompted by scamgr. There are three settings for password requirements, as shown in the following table:
2. Type the set passreq command followed by low, med, or high.
The following commands set the password requirements for a Sun Crypto Accelerator 6000 Board to high:
scamgr{mcaN@hostname, sec-officer}> set passreq high scamgr{mcaN@hostname, sec-officer}> set passreq Password security level (low/med/high): high |
Only security officer passwords may be changed with scamgr. Security officers can change their own password.
scamgr{mcaN@hostname, sec-officer}> set password Enter new security officer password: Confirm password: Security Officer password has been set. |
User passwords may be changed through the PKCS#11 interface with the Sun Java System Web Server modutil utility. Refer to the Sun Java System Web Server documentation for details.
This section describes how to populate keystores and how to list, enable, disable, and delete security officers and users.
There might be more than one security officer for a keystore. Security officer names are known only within the domain of the Sun Crypto Accelerator 6000 Board and do not need to be identical to any user name on the host system.
When creating a security officer, the name is an optional parameter on the command line. If the security officer name is omitted, scamgr prompts you for the name. (See Naming Requirements.) For example:
User names are known only within the domain of the Sun Crypto Accelerator 6000 Board and do not need to be identical to the UNIX user name for the web server process.
2. Type create user user-name.
When creating a user, the user name is an optional parameter on the command line. If the user name is omitted, scamgr prompts you for the user name. (See Naming Requirements.) For example:
Users must use this password when authenticating during a web server startup.
|
Caution - Users must remember their password so they can access their keys. There is no way to retrieve a lost password. |
| Note - The user account is logged out if no commands are entered for more than five minutes. This is a tunable option. See Set the Auto-Logout Time for details. |
You can list users associated with a keystore.
2. Type the show user command.
scamgr{mcaN@hostname, sec-officer}> show user User Status ----------------------------------------------------- web-admin Enabled Tom Enabled ----------------------------------------------------- |
You can list security officers associated with a keystore.
2. Type the show so command. For example:
| Note - Security officers cannot be disabled. Once a security officer is created, it is enabled until it is deleted. |
Users and security officers are enabled by default. Users may be disabled. Disabled users cannot access their key material with the PKCS#11 interface. Enabling a disabled user restores access to all of that user’s key material.
2. Type disable user user-name.
When enabling or disabling a user, the user name is an optional parameter on the command line. If the user name is omitted, scamgr prompts you for the user name. For example:
scamgr{mcaN@hostname, sec-officer}> disable user Tom User Tom disabled. scamgr{mcaN@hostname, sec-officer}> disable user User name: web-admin User web-admin disabled. |
2. Type the enable user user-name command.
When enabling a user, the user name is optional. For example:
scamgr{mcaN@hostname, sec-officer}> enable user Tom User Tom enabled. scamgr{mcaN@hostname, sec-officer}> enable user User name: web-admin User web-admin enabled. |
2. Type delete user user-name.
When deleting a user, the user name is an optional parameter on the command line. If the user name is omitted, scamgr prompts you for the user name. For example:
When deleting a security officer, the security officer name is an optional parameter on the command line. If the security officer name is omitted, scamgr prompts you for the security officer name. For example:
There are three types of backups that can be performed with the board: Device Configuration, Master Key, and Keystore.
This type of backup saves the global device configuration including FIPS 140-2 settings, DSO accounts and other settings. Only DSOs can perform this type of backup.
2. Type backup device /var/tmp/devconf.bak
An optional filename for the backup file can be supplied on the command line. If the filename is not supplied, you are prompted for it when the command is executed.
scamgr{mcaN@hostname, sec-officer}> backup device /var/tmp/devconf.bak Enter a password to protect the data: Confirm password: Backup to /var/tmp/devconf.bak successful. |
This backup is used with a specific keystore, and therefore must be done by a KSO. This backs up only the master key and other keystore specific settings, but does not backup the keystore data. This backup is useful for having new boards join an existing local or centralized keystore, where one board is already fully configured.
Keystores are stored on the host and encrypted in a master key. The master key for each keystore is stored in the firmware. For another board to use an existing keystore, the master key for that keystore must be loaded to that board using a master key backup file. Only the keystore security officer can backup a master key.
2. Type backup master-key /opt/backup-directory-name/master.bak.
The path name can be placed on the command line or if omitted, scamgr prompts you for the path name.
| Note - If the following command is executed in Multi-Admin mode, authentication is required by multiple security officers assigned the Multi-Admin role. |
3. Set a password for the backup data.
This password encrypts the master key in the backup file.
This is done on a specific keystore and must be done by KSOs only. This backs up the same data as a Master Key Backup, but additionally retrieves all the keystore data, and security officer and user accounts. You can use a full keystore backup file to completely restore a keystore when that keystore does not exist on the system (local) or in the LDAP repository (centralized).
Keystores are stored on the host and encrypted in a master key. The master key for each keystore is stored in the Sun Crypto Accelerator 6000 firmware. The entire keystore including the master key can be backed up for disaster recovery. This backup is good for disaster recovery.
2. Type backup keystore /opt/backup-directory-name/bkup.data.
The path name can be placed on the command line or if omitted, scamgr prompts you for the path name.
| Note - If the following command is executed in Multi-Admin mode, authentication is required by multiple security officers assigned the Multi-Admin role. |
3. Set a password for the backup data.
This password encrypts the master key in the backup file.
A site might have a strict security policy that does not permit the master key for a keystore to leave the hardware.
|
|
Caution - Once this command is entered, all attempts to back up the master key will fail. This lock persists even if the master key is rekeyed. The only way to clear this setting is to delete the keystore from the Sun Crypto Accelerator 6000 board with the delete keystorecommand. (See TABLE 3-4.) |
2. Type lock master-key. For example:
A site might have a security policy that does not permit access to a keystore after the board has been reset or powered off without approval by a keystore security officer (KSO). To restrict keystore access, a KSO can lock a keystore. Once a keystore is locked, it can be used only if it is enabled by a KSO using the enable keystore command. If the Sun Crypto Accelerator 6000 board is reset or powered off, the keystore will default back to the disabled state until it is re-enabled by a KSO.
2. Type lock keystore. For example:
After a reset or power cycle, a keystore that has been locked to prevent access can be accessed only if enabled by a KSO.
2. Type enable keystore. For example:
A keystore that has been locked to prevent access will default to the disabled state if the board is reset or powered off. A KSO can also disable the keystore manually.
2. Type disable keystore. For example:
The scamgr utility includes a special mode of operation called Multi-Admin mode. In this mode, certain commands require multiple security officers to authenticate and approve the command before it can complete successfully. Security officers must be in the Multi-Admin role before they can authenticate Multi-Admin commands.
When a Multi-Admin command is issued, no other general administration on the board can take place until either the command times out, is canceled by the security officer who started the command, or completes successfully. A timeout from 1 to 15 minutes must be set at or before Multi-Admin mode is enabled. See Set a Multi-Admin Command Timeout for more information. Also security officers must set the number of Multi-Admin role members required to authenticate any Multi-Admin command.
When a Multi-Admin command is initiated, the scamgr session from which it is started waits until one of three conditions occur: The command completes successfully, the command fails, or the command times out. Other Multi-Admin role members log in to the device using their respective scamgr sessions. During Multi-Admin mode commands, these role members can only authenticate the command in progress. If the initiating security officer’s scamgr session terminates unexpectedly, the security officer can log back in to the device and cancel the command. Otherwise, the board cannot be administered normally until the command times out.
The following commands require multi-admin authentication:
This section describes how to configure and manage Multi-Admin mode with the scamgr utility. First, you must identify your security officers and place them in the Multi-Admin role. You must have enough security officers in that role to satisfy the minimum number set with the set multiadmin minauth command. See Set the Minimum Number of Security Officers Required to Authenticate Multi-Admin Commands. If the number of Multi-Admin role members is below the minimum threshold, you cannot enable Multi-Admin mode.
2. Type enable authmember sec-officer.
If executed in Multi-Admin mode, this command requires authentication by multiple security officers assigned the Multi-Admin role. The following command assigns a security officer the Multi-Admin role.
scamgr{mcaN@hostname, sec-officer}> enable authmember sec-officer Added multi-admin role to Security Officer sec-officer. |
2. Type disable authmember so-name.
If executed in Multi-Admin mode, this command requires authentication by multiple security officers assigned the Multi-Admin role. For example:
scamgr{mcaN@hostname, sec-officer}> disable authmember sec-officer Removed multi-admin role from Security Officer rew. |
This command removes security officers from the Multi-Admin role only if they are in addition to the minimum required. This command exits only if a minimum number of security officers are assigned the Multi-Admin role. See Set the Minimum Number of Security Officers Required to Authenticate Multi-Admin Commands.
|
|
2. Type set multiadmin minauth minimum-role-members.
The minimum-role-members value must be at least two, and less than or equal to the total number of security officers on the system. In addition, if Multi-Admin mode is already enabled, the new value cannot exceed the number of members with the Multi-Admin role. If executed in Multi-Admin mode, this command requires authentication by multiple security officers assigned the Multi-Admin role.
For example, the following command sets the minimum number of required security officers to authenticate Multi-Admin commands.
scamgr{mcaN@hostname, sec-officer}> set multiadmin minauth 3 Multi-admin mode now requires 3 security officers to authenticate. |
2. Type set multiadmin timeout minutes.
The minutes value must be between 1 and 1440 minutes (1 day). If a value larger than 1440 is specified, the value will be set to 1440. If executed in Multi-Admin mode, this command requires authentication by multiple security officers assigned the Multi-Admin role.
For example, the following command changes the timeout for commands that require Multi-Admin mode authentication.
scamgr{mcaN@hostname, sec-officer}> set multiadmin timeout 3 New multi-admin timeout value is 3 minutes. |
When enabled, certain commands require multiple security officers to authenticate before the command can complete successfully. When this command is executed, the security officer is presented with the current Multi-Admin mode settings and is given the opportunity to change these settings before the command completes. This command does not accept the -y (yes to all) flag.
For example, the following command enables Multi-Admin mode.
This command requires authentication by multiple security officers assigned the Multi-Admin role.
For example, the following command disables Multi-Admin mode.
2. Type enable authmember sec-officerN.
where N is the number of the security officer.
For example, with the minimum number of required security officers set to three, adding additional security officers requires the authorization of three different security officers, including the initiating security officer, to authenticate before this command can complete.
Execute the following command on the initiating security officer’s scamgr session.
3. Ask other security officers to log in from their respective scamgr sessions and authorize the command.
|
|
2. Type disable authmember sec-officerN.
where N is the number of the security officer.
For example, the following command is canceled. This command must be entered on the initiating security officer’s scamgr session.
To cancel the command, the initiating security officer must either close the current scamgr session or log in with a second scamgr session.
If the scamgr session from which the command was initiated is still active, the following message is displayed.
3. Ensure that other security officers do not authenticate the command.
For example, the following command is issued by security officer.
|
|
1. Log in as a non-Multi-Admin security officer.
2. Ask Multi-Admin security officers to log in and athorize the command (if they don’t the connection is closed).
If the Multi-Admin security officers do not authorize the command, the connection is closed.
|
|
2. Type a command as a security officer without Multi-Admin role permissions.
The command fails. For example:
| Note - You must log into scamgr as a device security officer (DSO) to perform the procedures in this section. You cannot manage boards if you are logged in as a keystore security officer (KSO). For information on DSOs and KSOs, see Device and Keystore Security Officers. |
You can access the scamgr utility remotely or locally with a direct input device (see Direct Board Administration.
|
1. Start the scamgr utility by logging in as a DSO.
where N is the number of minutes before a security officer is automatically logged out. A value of 0 disables the automatic logout feature. The maximum delay is 1,440 minutes (1 day). A newly initialized board defaults to 5 minutes.
The following command changes the auto-logout time for a security officer to 10 minutes:
|
1. Start the scamgr utility by logging in as a DSO.
This command displays the hardware and firmware versions for that board, the MAC address of the network interface, the status (Up, Down, speed, duplex, and so on) of the network interface, and the keystore name and ID. For example:
|
You can update the firmware for the Sun Crypto Accelerator 6000 Board as new features are added.
1. Start the scamgr utility by logging in as a DSO.
2. Type load firmware path-name.
where path-name is the path to the firmware file.
A successful update of the firmware requires you to manually reset the board with the reset command. When you reset the board, the currently logged in security officer is logged out (see Reset the Board). For example:
|
In certain situations, it might be necessary to reset the board. To do this, you must issue the reset command. You are asked if this is what you want to do. Resetting a Sun Crypto Accelerator 6000 Board might temporarily cease the acceleration of cryptography on the system unless there are other active Sun Crypto Accelerator 6000 boards able to take over the load. Also, this command automatically logs you out of scamgr, so you must reconnect to the device by logging back into scamgr if you want to continue administering it.
1. Start the scamgr utility by logging in as a DSO.
3. Type y to proceed, type n to cancel.
scamgr{mcaN@hostname, sec-officer}> reset WARNING: Issuing this command will reset the the board and close this connection. Proceed with reset? (Y/Yes/N/No) [No]: y Reset successful. |
|
If your security policy changes, you might want to use new keys as the master key or remote access key. The rekey command enables you to regenerate either of these keys, or both.
Rekeying the master key causes the keystore to be re-encrypted under the new key, and invalidates old back up files. Create a backup of the master key whenever it is rekeyed to ensure safe disaster recovery. If you have multiple Sun Crypto Accelerator 6000 Boards using the same keystore, you need to back up this new master key and restore it to the other boards.
Rekeying the remote access key logs the security officer out, forcing a new connection that uses the new remote access key.
1. Start the scamgr utility logging in as a KSO.
3. Specify which keys to rekey.
You may specify one of three key types when issuing the rekey command:
|
Rekeys the remote access key. Logs the security officer out. |
|
The following is an example of entering a key type of all with the rekey command:
4. Backup the master key to enable disaster recovery (see Back Up a Master Key.
|
There are two methods of clearing a board of all its key material. The first method is with a hardware jumper (shunt). This form of zeroizing returns the board to its original factory state (Failsafe mode). (See Zeroizing the Sun Crypto Accelerator 6000 Hardware to the Factory State.) The second method is to use the zeroize command.
| Note - The zeroize command removes the key material, and leaves any updated firmware intact. This command also logs the security officer out upon successful completion. |
|
Diagnostics can be performed from the scamgr utility and from the SunVTS software. The diagnostics command in scamgr covers three major categories in the Sun Crypto Accelerator 6000 hardware: general hardware, cryptographic subsystem, and network subsystem. Tests for general hardware cover DRAM, flash memory, the PCI bus, the DMA controller, and other hardware internals. Tests for the cryptographic subsystem cover random number generators and cryptographic accelerators. Tests on the network subsystem cover the sca device.
You can also administer the board with a direct serial port connection. See Direct Input Devices for details on configuring this port and the suggested serial input device. Most of the commands supported for connecting remotely with scamgr are also supported with the direct interface. The output of direct interface commands is abbreviated to support the limited output capabilities of hand-held devices. The following commands are not supported on the direct interface:
There are also additional commands supported on the local interface that are not available when connecting remotely with scamgr. These commands are primarily intended to support financial services routines and USB backups. See Chapter 5 for details of the financial services interface. The following commands are supported on the local interface only:
To initiate the direct administration interface, a security officer must press the Enter key on the direct input device and log in to the system. The following example shows a security officer logging in to the system and requesting a list of available commands.
When a backup operation is performed on the local interface, the master key is written to a USB mass storage device rather than a host disk. See Direct Input Devices for details on the USB port and the suggested USB backup device.
Using the backup command through a local interface works the same as accessing scamgr remotely unless the board is in FIPS mode. When in FIPS mode, the USB Wrapping Key (UWK) is required to wrap all data written to the USB device. The UWK is entered with the local interface and must be entered using split knowledge procedures. The number of key components must be at least two. The security officer who initiates the UWK entry must set the UWK.
Each security officer must authenticate to the system with a user name and password before entering a component. To ensure accuracy, each key component must be entered twice. The UWK is an AES key and can be either 128, 192, or 256 bits in length. The length of the key is determined by the length of the first component entered. Once the UWK is entered, it is used to wrap all subsequent USB backup files.
The UWK is not required when not in FIPS mode, however, it can be always be entered for added security. A new UWK can be entered at any time regardless of the FIPS mode setting.
When restoring a card using a USB backup file for which a UWK was used, the security officers are presented with a series of prompts that enable them to reenter the required UWK components. Since the board is in an uninitialized state, each security officer need not authenticate to the board before entering a component. The following example shows the initialization of a board using the local interface and a USB backup file for which the UWK was used.
The scadiag utility provides a command-line interface to the board that enables superusers to perform administrative tasks without authenticating as a security officer. Command-line options determine the actions that scadiag performs.
To access the scadiag utility easily, place the Sun Crypto Accelerator 6000 tools directory in your search path, for example:
The scadiag command-line syntax (described in TABLE 3-8) for both the Oracle Solaris OS and Linux is as follows:
The Oracle Solaris specific command-line syntax for scadiag is as follows:
The Linux specific command-line syntax for scadiag is as follows:
| Note - In the scadiag option examples in this section, mcaN is the board’s device name where N corresponds to the Sun Crypto Accelerator 6000 device instance number. |
TABLE 3-8 describes the supported options for the scadiag utility.
The following is an example of the -b option:
The following is an example of the -d option:
The following is an example of the -f option:
The following is an example of the -k option:
The following is an example of the -l option:
The following is an example of the -m option (note that the diag option is Oracle Solaris only):
# scadiag -m diag mca0 Device mca0 is now in diagnostic mode. % scadiag -l mca0 Device mca0 State : Diag Status: Initialized |
The following is an example of the -r option:
# scadiag -r mca0 Resetting device mca0, this may take a minute. Please be patient. Device mca0 reset ok. |
The following is an example of the -s option:
The following is an example of the -u option:
# scadiag -u fw-file mca0 Updating firmware on mca0, this may take a few minutes. Please be patient. Firmware update on mca0 complete. Reset required to activate new firmware. |
The following is an example of the -V option:
# scadiag -V scadiag (Sun Crypto Accelerator 6000) Copyright 2006 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. |
The following is an example of the -z option:
# scadiag -z mca0 Zeroizing device mca0, this may take a few minutes. Please be patient. Device mca0 zeroized. |
Two service daemons are provided for the board: scad and scakiod. The scad service performs administrative I/O functions between the scamgr(1M) utility and the firmware. The scakiod service performs keystore I/O services. The Fault Management Resouce Identifiers (FMRIs) for these services are svc:/device/scad and svc:/device/scakiod.
|
Use the svcadm(1m) command to start and stop the services.
You can specify both services in a single command to start both simultaneously.
TABLE 3-9 lists and describes the service parameters of the scad service.
TABLE 3-10 lists and describes the service parameters of the scakiod service.
Configuration parameters are under the SMF property group config.
Use the svccfg(1m) command to list service properties. For example:
The following is an example of listing the service properties for the scakiod service:
Use the svccfg(1m) command to modify a property as follows:
For example, the following command defines the hostbind property:
The following algorithms are not enabled by default to maximize performance.
Enable these algorithms as needed by adding entries to /kernel/drv/mca.conf file. One example for enabling certain algorithms is to use them with sensitive keys protected by the board.
|
Add enable-sha512=1; to the /kernel/drv/mca.conf file.
|
Add enable-rc2cbc=1; to the /kernel/drv/mca.conf file.
|
Add enable-multi-part-md5=1; to the /kernel/drv/mca.conf file.
|
Add enable-multi-part-sha1=1; to the /kernel/drv/mca.conf file.
|
Add enable-multi-part-sha512=1; to the /kernel/drv/mca.conf file.
|
Add enable-hmac=1; to the /kernel/drv/mca.conf file.
Administering the board on Linux platforms is similar to administering it on the Oracle Solaris OS as described in this chapter. The differences are given in this section.
The scamgr program is installed in the /opt/sun/sca6000/bin directory. You can put this directory in your path or start the program directly with the following command:
A newly installed board must be initialized before you can use it (see Initializing the Board With scamgr). In addition, the board must be re-initialized after performing a zeroize (see Appendix E) with the scamgr program (see Using the scamgr Utility).
The board must be stopped and restarted after initialization or a zeroize.
|
|
The scadiag program is installed in the /opt/sun/sca6000/sbin directory. You can place this directory in your path or directly launch the program with the following command:
The scad and scakiod daemons are installed in /opt/sun/sca6000/sbin directory. Do not start or stop these daemons manually. Stop and start the board to stop and start these daemons (see Stop the Board on a Linux Platform and Start the Board on a Linux Platform.
| Sun Crypto Accelerator 6000 Board User’s Guide for Version 1.1 | E39851-01 |
|
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
Perform a Board Initialization