A Vendor’s Guide to DSD Cryptographic Evaluations

1. What is a DSD Cryptographic Evaluation and why is it required?

A DSD Cryptographic Evaluation (DCE) is an unconstrained search and testing for cryptographic vulnerabilities. DSD performs this search so Australian government agencies can rely on the strength and quality of the cryptographic security they use to protect official information and systems.

The result of a DCE is a published consumer guide on the EPL that provides guidance to Australian government agencies on the security classification of information that can be stored or transmitted in accordance with the Information Security Manual (ISM), which can be downloaded from the DSD website: www.dsd.gov.au.

In Australia, ICT security products may be evaluated for use by Australian government agencies through the Australasian Information Security Evaluation Program (AISEP), DSD High Assurance evaluation program or a DSD unique evaluation.

A DCE is required if:

1. An ICT security product enters the AISEP containing cryptographic functionality in the Target of Evaluation (TOE), and a an Australian government agency will rely on this cryptographic functionality for reducing the storage and physical transfer and/or electronic transit encryption requirements of RESTRICTED information or higher; or
2. An Australian Government agency selects a product on the Evaluated Products List (EPL) that is not AISEP evaluated (including products from the Common Criteria portal: http://www.commoncriteriaportal.org) and the ICT security product contains cryptographic functionality that will be used to reduce the storage and physical transfer and/or electronic transit encryption requirements of RESTRICTED information or higher.

An example where a DCE would and would not be required on a product containing cryptography is:

3. If an Australian government agency wanted to use a hard-disk encryption product to reduce the storage and physical transfer requirements of RESTRICTED information on a laptop to those of UNCLASSIFIED, a DCE would be required.
4. If an Australian a government agency wanted to use an ICT security product that provided file-based encryption, auditing and access control features, but only wished to use the access control features, a DCE would not be required.

Examples of cryptographic evaluations conducted in other nations include the UK's CAPS scheme, the USA's FIPS-140 and the USA and Canadian Cryptographic Module Validation Program (CMVP). The results and certification/validation of these cryptographic evaluations are not a replacement for a DCE for Australian government agencies.

2. What is the purpose of a DCE?

The purpose of a DCE is to analyse a product to determine whether the security architecture and cryptographic algorithms used have been implemented correctly and are appropriately strong for the product’s intended use by the sponsoring government agency.

3. What is the relationship between an AISEP evaluation and a DCE?

DSD performs cryptographic evaluations independently of the AISEP. However, the depth of testing in the DCE is determined by the risks associated with the use of the product, which are dependent on the sponsor’s deployment of the product and the classification handling involved. These details should be specified in the sponsorship letter to determine resourcing and effort involved. Information on the AISEP can be found on DSD’s webpage at:
http://www.dsd.gov.au/infosec/evaluation_services/aisep_pages/aisep_faqs.html

4. If a vendor’s ICT security product has been evaluated under a Common Criteria scheme other than the AISEP, how do I have it listed on the DSD EPL page?

An Australian government agency must request and require (see Qu. 1) that an ICT security product undergo a DCE. A DCE request is submitted to DSD through a sponsorship letter. Further information on sponsorship is provided at:
http://www.dsd.gov.au/infosec/evaluation_services/epl/dsdproducts.html

DCE requests are actioned on the basis of Australian government need and priority. It is recommended that Australian government agencies first consider the use of a certified product that has completed the DCE process for suitability to their requirements in accordance with the ISM.

5. What tests are performed during a DCE?

DCE testing involves a combination of open source and DSD in-house tests to ensure the correct implementation of encryption algorithms as well as assessing the quality of the surrounding cryptographic architecture.

Depending on the type and technology of ICT security product undergoing a DCE, areas of testing may include: packet sniffing, black box testing, source code review, key management analysis and Random Number Generation (RNG) evaluation.

6. Are there particular cryptographic algorithms or protocols that should be implemented in the ICT security product for Australian government?

Yes. All ICT security products implementing cryptography destined for use by Australian government agencies must use DSD approved cryptographic algorithms (DACAs) and DSD approved cryptographic protocols (DACPs). Further information of this requirement is explained in the ISM:
http://www.dsd.gov.au/library/infosec/ism.html

7. What information and support should vendors provide in assisting a DCE?

1. A technical and/or engineering point of contact within the company (preferably located in Australia) to answer any questions that may arise during the DCE.
2. Technical documentation including descriptions of protocols, key management, algorithms and data formats.
3. Offline access to the full source code of the ICT security product.

8. Why does DSD require source code in order to perform a DCE?

To achieve a higher level of confidence in the implementation and architecture of the cryptographic security, greater scrutiny must be applied through an independent review of the source code. The provision of source code usually expedites the cryptographic evaluation as fewer assumptions are made about the ICT product, given that evaluators can view the full implementation as they require it.

9. When can DSD begin the DCE?

Outside of Australia, a DCE can only be performed on Common Criteria certified products. This includes all Common Criteria recognised certification schemes. The CC Security Target (ST) and Certification Report (CR) must be published/publicly available before the DCE can begin. The commencement is also subject to information provided by the vendor as explained in Qu. 7.

For products undergoing CC evaluation in the AISEP, the commencement date of a product’s DCE will depend on the provision of the information stated in Qu. 7, in addition to the ICT product itself (hardware, software). The government sponsorship(s) for the DCE also determines the priority of the evaluation.

Vendors are encouraged to be proactive in seeking advice and to be cooperative in providing information to facilitate the DCE process.

10. How long does a DCE take?

The DCE process generally takes several months. This is an estimation from the DCE commencement date, which is separate to an AISEP evaluation commencement date. The vendor will be formally advised of the DCE commencement date by DSD. The time taken is greatly dependent on and influenced by the level of cooperation from the vendor and whether any security vulnerabilities are found during the DCE. If security vulnerabilities are detected in the ICT product, continuation of the DCE will depend on the implementation of a suitable fix if one can be found.

If the Australian government sponsor(s) withdraws sponsorship the DCE will usually halt until new or existing sponsorship is reinstated.

11. Do vendors need a Non-Disclosure Agreement in place with DSD before commencing a DCE?

DSD does not require a Non-Disclosure Agreement (NDA) be in place prior to starting a DCE. Though if one is requested, an NDA can be negotiated between DSD and the vendor. It should be noted that this can be a lengthy process that will postpone the DCE commencement until the NDA is finalised. To reduce delays caused by an NDA, vendors may use the DSD standard NDA template, which is available upon request.

12. Does obtaining FIPS-140 accreditation mean that the ICT product does not need to go through a DCE?

In accordance with the ISM, FIPS-140 accreditation does not replace a DCE. However, providing all relevant FIPS accreditation documentation may assist the DCE process.

13. What is the outcome of a DCE?

The completion of a DCE results in a published consumer guide for the product’s use by Australian government agencies. The consumer guide is listed with the ICT security product’s completed AISEP or CC evaluation result on the EPL. For the benefit of Australian government agencies, consumer guides specify the security classification of information that the evaluated ICT product can be used to protect. See Qu. 14 for an explanation of consumer guides.

14. What is a Consumer Guide?

Consumer guides are found on the EPL and are for the benefit of Australian government agencies. A consumer guide is published for ICT security products that have completed a DCE and sometimes where clarification of use for Australian government was deemed necessary. Consumer guides give a brief description of the product, detail the scope of the evaluation and include recommendations for secure cryptographic usage. Consumer guides also specify the classification of data that the product can be used to protect.

Products on the EPL that do not have a consumer guide include those that do not have sponsorship for the use of cryptographic security and products that do not contain cryptographic security.

15. What is the Evaluated Products List and where can I find it?

The Evaluated Products List (EPL) provides a comprehensive list of DSD evaluated ICT security products that meet the needs of Australian government agencies in securing official information. ICT products that are progressing through or have completed a DCE are listed on the EPL. The EPL can be found on the DSD website: http://www.dsd.gov.au/infosec/evaluation_services/epl/epl.html

16. Are there any costs incurred by the vendor for a DCE?

DSD does not charge evaluation fees to the vendor for conducting a DCE or for producing a consumer guide. However, the vendor is responsible for arranging delivery of the information, software and/or hardware to DSD (if secure electronic means is not a viable option) and the provision of licences required by DSD in order to conduct the DCE.

17. Acronym Guide

Acronym	Description
AISEP	Australasian Information Security Evaluation Program
CR	Certification Report
DSD	Defence Signals Directorate
DCE	DSD Cryptographic Evaluation
DACA	DSD Approved Cryptographic Algorithm
DACP	DSD Approved Cryptographic Protocol
EAL	Evaluation Assurance Level
EPL	Evaluated Products List
ICT	Information and Communications Technology
ISM	(Australian Government) Information Security Manual
NDA	Non-Disclosure Agreement
ST	Security Target
TOE	Target of Evaluation