|
6.1
Key Pair Generation and Installation
6.1.1 Key pair generation
6.1.2
Private key delivery to end entity
6.1.3 Public key delivery to certificate issuer
6.1.4 CA public key delivery to users
6.1.5
Key sizes
6.1.6 Public key parameters generation
6.1.7 Parameter quality checking
6.1.8 Hardware/software key generation
6.1.9 Key usage purposes (as per X.509 v3 key usage field)
6.2 CA Private Key Protection
6.2.1 Standards for cryptographic module
6.2.2 Private key (n out of m) multi-person control
6.2.3 Private key escrow
6.2.4 Private key backup
6.2.5 Private key archival
6.2.6 Private key entry into cryptographic module
6.2.7 Method of activating private key
6.2.8 Method of deactivating private key
6.2.9 Method of destroying private key
6.3
Other Aspects of Key Pair Management
6.3.1 Public key archival
6.3.2 Usage periods for the public and private keys
6.4
Activation Data
6.4.1 Activation data generation and installation
6.4.2 Activation data protection
6.4.3 Other aspects of activation data
6.5
Computer Security Controls
6.5.1 Specific computer security technical requirements
6.5.2 Computer security rating
6.5
Computer Security Controls
6.5.1 Specific computer security technical requirements
6.5.2 Computer security rating
6.6
Life Cycle Technical Controls
6.6.1 System development controls
6.6.2 Security management controls
6.6.3 Life cycle security ratings
6.7
Network Security Controls
6.8
Cryptographic Module Engineering Controls
6.1
Key Pair Generation and Installation
6.1.1 Key pair generation
Key pair generation on the subscriber’s local system ensures
that only the user and no one else knows the private key.
COMTRUST key pairs are generated in COMTRUST’s Offline CA
(Offline CA houses the cryptographic module) on hardware tokens.
6.1.2
Private key delivery to end entity
As the key pair is generated on the subscriber’s local system,
hence the delivery of the private key is achieved in a secure
manner on the subscriber’s system.
6.1.3
Public key delivery to certificate issuer
PKCS#10 construction is employed to deliver the public key
to COMTRUST, thus ensuring against tampering and proving that
the sender is in possession of the corresponding private key.
6.1.4
Public key delivery to users
COMTRUST will post public key certificates at COMTRUST directory
for retrieval by subscribers.
6.1.5
Key sizes
COMTRUST CA key pair is 2048 bits. Subscriber key pairs will
range from 1024 bits to 2048 bits.
6.1.6
Public key parameters generation
Not applicable
6.1.7
Parameter quality checking
Not applicable
6.1.8
Hardware/software key generation
Not applicablesee section 6.2.1
6.1.9
Key usage purposes (as per X.509 v3 key usage field)
Key Usage: Digital Signature, Key Encipherment
Key Usage: Key Encipherment
Extended Key Usage: Server Authentication, Step-up
certificates (Server
Gated Cryptography)
6.2
CA Private Key Protection
6.2.1 Standards
for cryptographic module
COMTRUST’s cryptographic module offers safe storage of keys
within the FIPS 140-1 Level 3 certified product. The CA key
and certificates are stored on industry standard smart cards.
6.2.2
Private key (n out of m) multi-person control
Access to cryptographic module containing the root CA requires
the insertion of cryptographic hardware tokens into the cryptographic
signer. A minimum number of required hardware tokens out of
the total numbers of hardware tokens must be inserted one
at a time to access the cryptographic module.
6.2.3
Private key escrow
Not Available
6.2.4
Private key backup
CA private key back-ups are performed to support disaster
recovery plan. Performing a cryptographic operation creates
a high security backup of the private key. The operation encrypts
the private key, splits it into two parts and stores them
on separate hardware tokens. These backups are securely stored
and are subject to extensive multi tier security measures.
6.2.5
Private key archival
Not Available
6.2.6
Private key entry into cryptographic module
An authorized person makes private key entry into the cryptographic
module in a special state of operation. The private key is
stored in split hardware tokens for additional security.
6.2.7
Method of activating private key
COMTRUST hardware token utilize PIN based activation mechanism.
The PIN is generated during token initialization and is split
into various shares for enabling multi-party access control.
6.2.8
Method of deactivating private key
The private key will deactivate itself as soon as it is removed
from the cryptographic module.
6.2.9
Method of destroying private key
Hardware token’s “zeroize” command will destroy the private
key, where required.
6.3
Other Aspects of Key Pair Management
6.3.1 Public key archival
The public key is archived along with the archival of the
certificate.
6.3.2
Usage periods for the public and private keys
|
CERTIFICATE ISSUED BY: |
DEMONSTRATION CERTS |
USER CERTS CLASS 1 |
BUSINESS USER CERTS |
SERVER CERTIFICATES |
|
COMTRUST TO END-USER/ SUBSCRIBER |
30days |
|
- One year unless earlier revoked
- Two
years unless earlier revoked
|
- One year unless earlier revoked
- Two
years unless earlier revoked
|
All certificates shall be considered valid upon acceptance by the subscriber which shall occur when e-mail containing URL to download certificate is sent to the subscriber. The starndard operational periods for the various classes of certificates, calculated from issuance of certificates (as opposed to acceptance), are as follows (subject to earlier termination of the operational period due to
suspension or revocation
Approaching end of the first year of certificate validity,
Comtrust will send Certificate Renewal reminder e-mails to
subscribers who have subscribed to certificates with one-year
validity. Upon subscriber request for renewal, Comtrust will
contact the subscriber for necessary documentation to validate
and authenticate the renewal request. Upon successful
validation, subscriber’s certificate will be renewed for one
more year.
6.4
Activation Data
6.4.1 Activation data generation and installation
The activation data is protected by PIN, which is automatically generated. Furthermore, it is split into multiple hardware tokens to ensure multi-party control of this sensitive information.
6.4.2 Activation data protection
Activation data is protected by splitting it and storing it on multiple hardware tokens with each hardware token in the possession of a trusted employee.
6.4.3 Other aspects of activation data
Not applicable.
6.5 Computer Security Controls
6.5.1 Specific computer security technical requirementsa
The operating system used by COMTRUST has to undergo rigorous security evaluations by an independent third party.
6.5.2 Computer security rating
All critical components of Comtrust CA use HP UX (version 11.0) operating system whereas some of the associated components are based on WindowsNT 4.0 operating system. All components of Comtrust’s PKI system are using Oracle (version 8.0) databases.
6.6 Life Cycle Technical Controls
6.6.1 System development controls
Not Applicable
6.6.2 Security management controls
Not Applicable
6.6.3 Life cycle security ratings
Not Applicable
6.7 Network Security Controls
In order to reduce the threats to network security, a multi layer system has been implemented. These layers of security include firewalls and intrusion detection systems, SSL protocols. System security is monitored round the clock by shifts of operations team. All key system statistics and events are logged for reference.
6.8 Cryptographic Module Engineering Controls
Refer to section 6.2
|
