PD-0114: Meeting the ADO_DEL.3 Requirement

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

Is a vendor required to implement a delivery scheme that absolutely prevents modification of the product, as is required by ADO_DEL.3, or is that requirement too stringent? Can passive measures to detect modifications and alert recipients of them (e.g., by way of a broken seal or disablement of the product) be used to meet ADO_DEL.3?

Resolution

There are two issues involved here. They are:

1. Can passive measures (e.g., seals) provide the same delivery assurance traditionally implemented by active measures (e.g., hand delivery and chain of custody)?

2. Is the ADO_DEL.3 requirement overstated or unattainable?

The requirement may be effectively met by passive measures put in place by a vendor. Note well, though, that the particular measures must be carefully considered by the evaluators to ensure they provide functionality equivalent to that usually provided by 'active' technologies.

In regard to the second issue: the requirement cannot be absolutely satisfied in all circumstances; it is better interpreted to mean that modifications must be detected rather then prevented; and the current wording of ADO_DEL.3 should be used only in EAL7 evaluations.

Support

Historically, requirements involving the prevention of modification of secure products have used software or hardware that contains a secret, (e.g. a crypto algorithm or an encryption key). Some of these secure products have utilized active circuitry within the products to delete the secret if the enclosure is opened. However, there is no requirement that active measures must be used. Correlatively, there need be no secret stored within the product.

Furthermore, it is possible for a vendor to implement a combination of passive measures to detect modification of a TOE during the delivery process and to alert the recipient of the modification or modification attempt in some manner. Those passive measures may include procedures, packaging, and couriers. It is expected that those measures will do any or all of the following:

1. Avoid or detect any tampering with the hardware and physical media shipped as the TOE.

2. Detect masqueraded deliveries of the TOE (ADO_DEL.3.3C).

3. Conceal knowledge of shipment of the TOE.

4. Avoid or detect interception of the TOE during the delivery process.

5. Avoid the delay of the TOE during distribution.

Addressing the above issues should provide ways of detecting most any modification short of what a well-funded and ruthless enemy could accomplish.

Note that the previous paragraphs of this support section refer to detection rather than prevention. ADO_DEL.3 is unattainable using today's technology. It reads:

"The delivery documentation shall describe how the various procedures and technical measures provide for the prevention of modifications, or any discrepancy between the developer's master copy and the version received at the user site."

It is manifestly impossible to prevent any imaginable modification of a product in transit. For example, entities exist today that could intercept a parcel while it is in transport, swap the contents with modified media, and replace the original seals with duplicates. What the requirement should read and what has been passed on to the CC Part 3 rewrite team, is "… provide for the detection of modifications …". Until CC V3.0 is released, the current ADO_DEL.3 component should probably not be used outside of an EAL7 evaluation effort.

Modification History:

2004-11-22

PD Created. (October 2004 ODRB Agenda Item 3.a.iv)

References:

• Common Criteria for Information Technology Security Evaluation - Part 3: Security Assurance requirements, January 2004, Version 2.2, CCIMB-2004-01-003, Incorporated with interpretations as of 2002-02-28

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0239