6 Technical security controls

6.1 Key Pair Generation and Installation

119. Subscriber key pairs must be 1024 bit RSA. CAs' keys may be 1024-bit or 2048-bit RSA.

120. Each key pair should be generated using a S.E.E. Steering Group approved key generation algorithm or system. Any keys passed between the CA and the Subscriber at this time must be either delivered in an on-line transaction in accordance with PKIX-3 Certificate Management Protocol, or via an equally secure manner.

121. Keys may be used for authentication, message integrity and session key establishment. Only CA signing keys must be permitted for signing certificates and CRLs.

122.The certificate keyUsage field must be used in accordance with PKIX-1 Certificate and CRL Profile.

123. The digitalSignature key usage value must be present in all certificates.

124. keyCertSign and cRLSign values must only be present in CA certificate-signing certificates.

6.2 Private Key Protection

125. Each Entity must physically protect their private keys from disclosure and tampering.

126. Subscriber private keys for PASSPORT and BUSINESS CARD certificates must be stored and processed in hardware cryptomodules (e.g. a smartcard, PC card, USB token, etc)

127. Subscriber private keys for ASSOCIATE certificates may be software based or stored and processed in hardware cryptomodules.

128. The cryptomodule must be protected from theft or misuse to a similar level to a driver's licence or credit card.

129. Private keys for server and other devices may be software based or stored and processed in hardware cryptomodules.

130. Subscriber's private keys may be backed up by the Subscriber, the CA, or a third party on behalf of the Sponsor on the proviso that the back-up keys are not stored on-line, never reside outside New Zealand, and are protected from physical harm and compromise. They should be stored in an encrypted and password protected form (using Triple DES, AES or equivalent).

131. Subscribers must be authenticated to their cryptographic modules before their private keys are activated (e.g. by a PIN, password or biometrics comparision).

132. Whenever private keys are inactive they must be available only in an encrypted form.

133. The cryptomodule and/or computer should also include mechanisms to prevent extraction of the private key(s) by an unauthorised user or malicious software.

134. All keys (including CA keys) must have validity periods of no more than FIVE years, except for 2048 bit CA keys which may have a validity period of up to TWENTY years.

135. The S.E.E. Steering Group reserves the right to make such changes as are required, if in their opinion, any deficiency in the security of the PKI is suspected.

6.3 Other Aspects of Key Pair Management

136. No stipulation.

6.4 Activation Data

137. Any activation data such as passwords and shared secrets (e.g. between a subscriber and their CA) must be unpredictable and unrelated to other user's activation data.

138. Subscribers must have the capability to change their passwords at any time.

139. The cryptographic token should include a facility to temporarily lock the token after a predetermined number of login attempts, if a reusable password scheme is used.

6.5 Computer Security Controls

140. The Certification Authority must include the following system security functionality:

• Unique identification and authentication of CA operators;

• System controlled access to the CA functions;

• Use of cryptography for session communication and database security;

• Archival of CA and Subscriber history and audit data; and

• Self-test of security related CA services and audit of security related events.

This functionality may be provided by the operating system, or through a combination of operating system, CA software, and physical safeguards.

141. The Certification Authority operating system and application software should be evaluated to an assurance level of at least ITSEC-E2 or Common Criteria EAL3 (refer to the AISEP area on www.dsd.gov.au/infosec or www.commoncriteria.org). Only the services required for the CA tasks - including CA management and protection - should be active on the CA server.

142. The Certification Authority system should include a virus detection system that is kept up to date.

6.6 Life Cycle Technical Controls

143. The Certification Authority must ensure

• That a documented configuration management procedure is used for installation and ongoing maintenance of the CA system.

• The CA personnel verify the CA software during installation, to confirm it:

  • Originated from the software developer;
  • Has not been modified prior to installation; and
  • Is the version intended for use.

144. The Certification Authority should ensure the integrity of the software and configuration is verified at regular intervals.

6.7 Network Security Controls

145. The Certification Authority server must be protected from attack through any open or general-purpose network it is connected to. Such protection must include the use of a firewall certified to EAL3 or better and configured to allow only the protocols and commands required for the operation of the CA.

146. The Certification Authority subnet should be protected against all AusCERT-published vulnerabilities.

147. A network intrusion detection system should be in place with appropriate procedures and responsibilities defined to manage any alerts appropriately.

148. The RA must satisfy all the physical, personnel and network security controls required for a CA site, in situations where an RA has Subscriber administration access on the CA server. Certificate-based authentication and encryption must be used to secure the connection.

6.8 Cryptographic Module Engineering Controls

149. All CA, RA and End-entity cryptographic functions must be performed in cryptographic modules that have been evaluated to a minimum of either FIPS140 Level 2, ITSEC level E2, or common Criteria EAL3.

150. The cryptographic application software used by RAs and End-entities should:

• Establish, transfer and use the public and private keys correctly and in a secure fashion;

• Be capable of performing the appropriate certificate validity and verification checking; and

• Report appropriate information and warnings to the user.

151. The Certification Authority, RA and Subscriber crypto-modules must support RSA 1024 and 2048 (as per PKCS#1) and SHA-1 (as per FIPS PUB 180-1 / ANSI X9.30).