- DSD evaluations
- About the EPL
- Protection Profiles
- About the AISEP
- Recommendation for DSD evaluation
- Certification guidance
- International partners
- Service providers
- Supporting documentation
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 test for cryptographic vulnerabilities. The Defence Signals Directorate (DSD) performs this search so Australian and New Zealand 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 Evaluated Product List (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).
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 discrete DSD evaluation.
A DCE is required if:
- an ICT security product enters the AISEP containing cryptographic functionality in the Target of Evaluation (TOE), and 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
- an Australian government agency selects a product on the EPL that is not AISEP-evaluated (including products from the Common Criteria Portal) 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.
Examples of where a DCE would and would not be required on a product containing cryptography are:
- 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.
- if an Australian 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 recommending 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 planned deployment of the product and the classification handling involved. These details should be specified in the letter of recommendation for evaluation to determine resourcing and effort involved. Information on the AISEP can be found at the AISEP FAQs.
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 EPL?
An Australian government agency must request and require that an ICT security product undergo a DCE. A DCE request is submitted to DSD through a letter of recommendation for evaluation in accordance with the recommendation process.
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 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 use?
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.
7. What information and support should vendors provide in assisting a DCE?
- 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.
- Technical documentation including descriptions of protocols, key management, algorithms and data formats.
- 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.
For products undergoing CC evaluation in the AISEP, the commencement date of a product’s DCE will depend on the provision of the information provided, in addition to the ICT product itself (hardware, software). The government letter of recommendation for evaluation 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 recommending Australian government agency withdraws its recommendation the DCE will usually halt.
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.
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 standard DSD 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.
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 have not been recommended for the use of cryptographic security or 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.
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
- Australasian Information Security Evaluation Program
- Certification Report
- Defence Signals Directorate
- DSD Cryptographic Evaluation
- DSD Approved Cryptographic Algorithm
- DSD Approved Cryptographic Protocol
- Evaluation Assurance Level
- Evaluated Products List
- Information and Communications Technology
- (Australian Government) Information Security Manual
- Non-Disclosure Agreement
- Security Target
- Target of Evaluation