hardcopy device protection profiles technical community update...

Hardcopy Device Protection ProfilesTechnical Community Update 2011 v2

A status report and proposal for achieving the Collaborative PP vision

Brian Smithson – Senior Principle Engineer – Ricoh Americas CorporationLead Editor, Protection Profiles – IEEE P2600 Working Group

IntroductionThis paper augments the presentation given by the author at the 12th International Common Criteria Conference (ICCC) in Malaysia on 28 September, 2011.

An updated version of the presentation may be found on http://grouper.ieee.org/groups/2600/presentations/12iccc/smithson-slides.pdf.

An updated version of this paper may be found on http://grouper.ieee.org/groups/2600/presentations/12iccc/smithson-paper.pdf.

ContentsIntroduction ..................................................................................................................................................1

Hardcopy devices and Common Criteria certification..................................................................................2

Hardcopy Device Protection Profiles ............................................................................................................4

International evaluation and recognition of HCD PPs ..................................................................................7

How are vendors using the PPs?...................................................................................................................7

What is next for Hardcopy Device PPs..........................................................................................................9

A proposal for how to achieve the Collaborative PP vision........................................................................15

Conclusions .................................................................................................................................................19

DisclaimersData on which this paper and presentation is based are believed to be accurate for the period in which the paper and presentation were written (August 2nd through September 8th, 2011). The number of Common Criteria projects in evaluation may be understated because vendors can choose not to disclose evaluation projects on scheme web sites. Opinions about new Protection Profiles and proposals about

2 Hardcopy devices and Common Criteria certification

structure and content of Protection Profiles and Supporting Documents are author and may not represent the position of Ricoh CompanyHardcopy Devices Technical Community.

Hardcopy devices and Common Criteria certificati

Historical certification trendsSince the first Common Criteria (CC) certification of a Hardcopy Device (HCD) in 2001, the number of certificates issued has grown significantly, and the cumulative number of certificates now well exceeds 200. Figure 1 shows new certificates issued each year (left axis) and the cumulative total certificates (right axis) with a trend line forecasting the next two years.

Hardcopy Device certification by vendorsAs Figure 2 shows, most of the major HCD vendors have certified or are currently certifying products.

Hardcopy devices and Common Criteria certification | HCD Update – 12th ICCC

tion Profiles and Supporting Documents are solely the responsibilityrepresent the position of Ricoh Company, Ltd., or any other members of the

Hardcopy Devices Technical Community.

s and Common Criteria certification

Historical certification trends

ost of the major

1 2 11 3165

105136

165216

0

10

20

30

40

50

60

2001 2002 2004 2005 2006 2007 2008 2009 2010

New

Cer

tific

ate

per y

ear

Hardcopy Device Certificates

New Certificates Poly. (Total Certificates)

(to date) (forecasts)

Canon3.8%

EFI0.8%

HP1.1%

Fuji Xerox 18.4%

Konica Minolta 22.6%

Lexmark 3.4% Ricoh

14.6%

Riso Kagaku0.4%

Dell0.4%

Certificates by Vendor,2001-2011

Figure 2- Hardcopy Device certificates, by vendor

Figure 1 - Hardcopy Device certificates, history and forecast

12th ICCC

responsibility of the members of the

241

050100150200250300350400

2010 2011 Tota

l Cer

tific

ates

(plu

s fo

reca

st)

Hardcopy Device Certificates

Poly. (Total Certificates)

2012 2013(to date) (forecasts)

EFI0.8%

Kyocera Mita6.9%

Océ3.8%

Oki Data 0.4%

Panasonic 1.9%Samsung

3.4%

Seiko Epson 0.4%

Sharp 8.0%

Toshiba 4.6%

Xerox 5.0%

Hardcopy Device certificates, by vendor

Hardcopy Device certificates, history and forecast

12th ICCC

Hardcopy Device certification EALsMost HCD certifications began at Evaluation Assurance Level 2 (EAL2), but as vendor competition and customer expectations have increased, EAL3 has become the baseline for HCD evaluation. Figure 3 shows that over 70% of HCD evaluations to date are at EAL3 or EAL3+.

Hardcopy Device evaluations by CC schemeHCDs have been certified under six CC schemes. Since most of the major HCD manufacturers are Japanese companies, the Japanese CC scheme oversees most of the HCD evaluations. Figure 4 shows the breakdown of evaluations by national CC scheme.

12th ICCC | Hardcopy devices and Common Criteria certification

certification

Evaluation Assurance Level 2 (EAL2),

customer expectations have increased, EAL3 has become the baseline for HCD

shows that over 70% of HCD evaluations to date are at

Hardcopy Device evaluations

HCDs have been certified under six CC schemes. Since most of the major HCD manufacturers are Japanese companies,

oversees most shows

EAL217.3%

EAL356.8%

EAL3+15.8%

EAL40.8%

maint.5.3%

Total projects, by EAL, 2001-

AU0.4%

DE4.9%

JP80.3%

KR3.7%

US9.4%

CA1.2%

Certificates by Scheme, 2001-2011

Figure 3 - Hardcopy Device certificates, by EAL

Figure 4 - Hardcopy Device certificates, by CC scheme

Hardcopy devices and Common Criteria certification 3

EAL2+4.1%

-2011

Hardcopy Device certificates, by EAL

Hardcopy Device certificates, by CC scheme

4 Hardcopy Device Protection Profiles

Hardcopy Devices as a Common Criteria categoryOn the Common Criteria Portal1, HCDs are listed with other types of devices in the “Other Devices” category. However, if HCDs are counted separately from those non-HCD devices, as is shown in Figure 5, we find that HCDs represent almost 16% of all CC certificates listed on the Portal. The only certificate category that is larger is “ICs, Smartcards” (at almost 28%).

Recently, the CCDB has agreed to give Hardcopy Devices its owncategory on the Common Criteria Portal.

Hardcopy Device Protection Profiles

Protection Profile DevelopmentIn 2004, major HCD vendors formed the IEEE P2600standards working group to develop security standards for hardcopy devices and to create a Common Criteria Protection Profile (PP).

During PP development, the P2600 working group solicited input from the (through the JBMIA3) the Japanese CC scheme.components from our lab, atsec4. Such input was essential goals:

1 http://www.commoncriteriaportal.org2 http://grouper.ieee.org/groups/2600/3 Japanese Business Machine and Information System Industries Association, 4 http://www.atsec.com

Hardcopy Device Protection Profiles | HCD Update – 12th ICCC

as a Common Criteria category

listed with other types of

Device Protection Profiles

Protection Profile Developmentformed the IEEE P26002

standards working group to develop security standards for hardcopy devices and to create a Common Criteria

During PP development, the P2600 working group solicited input from the United Statese Japanese CC scheme. We also received input and help authoring extended

. Such input was essential to the creation of HCD PPs that

http://www.commoncriteriaportal.orghttp://grouper.ieee.org/groups/2600/Japanese Business Machine and Information System Industries Association, http://www.jbmia.or.jp/

Trusted Computing

0.1%

Biometric Devices0.1%

Key Management2.3%

Detection Devices2.7%

Databases3.4%

Network Devices8.7%Other Devices –

not Hardcopy9.9%

Other Devices -Hardcopy

15.9%

ICs, Smartcards27.8%

Common Criteria Certificates by Category

Figure 5 - Hardcopy Devices as a separate category of all CC certificates

United States CC scheme andauthoring extended

PPs that fulfilled these

http://www.jbmia.or.jp/

Detection Devices2.7%

Databases3.4%

Digital Signatures3.9%

Access Control

4.8%

Data Protection4.8%

Operating Systmes

7.6%

Boundary Protection

8.1%

Network Devices

Hardcopy Devices as a separate category of all CC certificates

Can be applied to any of many configurations of hardcopy devices, fromto advanced multifunction devices.

Sufficiently abstract to accommpermit future innovation.

Follow the Common Criteria standardsguidelines for international evaluation of products and international recognition of certification.

Adoption by the U.S. Government as an approved PP for HCDs.

The initial development approach was presentedissued, the results and lessons learned from were presented8 at the 11th ICCC in Antalya, Turkey.

IEEE 2600.1™ and IEEE 2600.2™Two protection profiles were issued: IEEE 2600.12600.210. IEEE 2600.1 is designed to be used by government agencies and by enterprises where highly proprietary or regulated information is being processed. IEEE 2600.2 is designed to be used by enterprises where the information being processed isstringent governance requirements.

IEEE 2600.1 uses the EAL3 assurance package, augmented by ALC_FLR.2. as an IEEE standard, and also issued CC scheme. The choice of EAL3 plus ALC_FLR.2 was driven by commercial and government customer preferences, including those of U.S. government customers.

IEEE 2600.2 uses the EAL2 package, augmented by ALC_FLR.2. IIEEE standard, and also issued as a Common Criteria Protection Profile

Adoption and revision by the United States governmentIn June 2009, simultaneously with its issuancenamed PP, the “U.S. Government Protection ProfileRobustness Environments”. Adoption of IEEE 2600.1 by the U.S. government was one of the primary goals of the P2600 working group.

5 http://www.commoncriteriaportal.org/cc/6 http://www.commoncriteriaportal.org/files/operatingprocedures/cc7 http://grouper.ieee.org/groups/2600/presentations/8iccc/smithson.pdf8 http://grouper.ieee.org/groups/2600/presentations/11iccc9 http://standards.ieee.org/getieee/2600/10 Ibid.

12th ICCC | Hardcopy Device Protection Profiles

any of many configurations of hardcopy devices, from simple singleto advanced multifunction devices.

ufficiently abstract to accommodate different product designs and implementations

the Common Criteria standards5 and Common Criteria Recognition Arrangemenlines for international evaluation of products and international recognition of certification.

Adoption by the U.S. Government as an approved PP for HCDs.

was presented7 at the 8th ICCC in Rome, Italy. After PPs had been , the results and lessons learned from PP development and technical community organization

ICCC in Antalya, Turkey.

IEEE 2600.1™ and IEEE 2600.2™Two protection profiles were issued: IEEE 2600.19 and IEEE

. IEEE 2600.1 is designed to be used by government agencies and by enterprises where highly proprietary or regulated information is being processed. IEEE 2600.2 is designed to be used by enterprises where

not subject to as stringent governance requirements.

IEEE 2600.1 uses the EAL3 assurance package, augmented by ALC_FLR.2. In June, 2009, itissued as a Common Criteria Protection Profile through the United States

The choice of EAL3 plus ALC_FLR.2 was driven by commercial and government customer preferences, including those of U.S. government customers.

IEEE 2600.2 uses the EAL2 package, augmented by ALC_FLR.2. In February 2010, it was approved as an as a Common Criteria Protection Profile through the German CC scheme.

by the United States governmentsimultaneously with its issuance, IEEE 2600.1 was adopted as a

ment Protection Profile for Hardcopy Devices in Basic Adoption of IEEE 2600.1 by the U.S. government was

one of the primary goals of the P2600 working group.

p://www.commoncriteriaportal.org/cc/http://www.commoncriteriaportal.org/files/operatingprocedures/cc-recarrange.pdfhttp://grouper.ieee.org/groups/2600/presentations/8iccc/smithson.pdfhttp://grouper.ieee.org/groups/2600/presentations/11iccc/smithson.pdfhttp://standards.ieee.org/getieee/2600/

Hardcopy Device Protection Profiles 5

simple single-function

implementations, and to

Common Criteria Recognition Arrangement6 (CCRA) lines for international evaluation of products and international recognition of certification.

PPs had been and technical community organization

In June, 2009, it was approved through the United States

The choice of EAL3 plus ALC_FLR.2 was driven by commercial and government customer

n February 2010, it was approved as an through the German CC scheme.

6 Hardcopy Device Protection Profiles

Within a few weeks, however, the U.S.Government PPs, and was re-issuing those PPs as “interim” PPs at EAL2. IEEE 2600.1 was one Government PP that was not under the direct control of the the P2600 working group and inquireEAL3 to EAL2. Because the IEEE 2600revising the standard. In addition, there were copyright issues that made it financially irevise and reissue the standard with a different EAL.

At that time, it was mutually agreed that IEEE 2600.1 could remain as the U.S. Government PP for HCDs provided that the P2600 working group establish a project to develop a new PP in the U.S. scheme’s “tailored assurance” approach For that purpose, the P2600 working group established IEEE Standards Association.

In mid-2010, the U.S. scheme inquired abo2600.1 (EAL3). The differences are in two areas:

1. IEEE 2600.1 requires protection of data in motion. IEEE 2600.2 does not.2. IEEE 2600.1 has auditable events that are not

to be collected in audit logs is somewhat more extensive in IEEE 2600.1 than it is in IEEE 2600.2.

In November, 2010, the U.S. scheme issued a Policy Letter #20IEEE 2600.2 augmented with changes outlined in that policy as the U.S. Approved PP. addresses protection of data in motion2600.1, but inexplicably, it does not address the addit

IEEE 2600.1 would no longer be accepted for new evaluations in the U.S. scheme. However, products claiming conformance either to IEEE 2600.1 or to IEEE 2600.2 with those augmentations outside of the U.S. would be recognized as complaint with the new U.S. Approved PP (i.e., IEEE 2600.2 plus augmentations).

The new “U.S. Government Protection Profile for Hardcopy Devices Version 1.0 (IEEE Std. 2600.2-2009)” was postedwith a reference to Policy #20, and protection profile and validation report but

The old “U.S. Government Protection Profile for Hardcopy Devices in Basic Robustness Environments” has been archived and is no 2600.1, however, remains in place and can be used.

11 http://www.niap-ccevs.org/policy/ccevs/policy12 http://www.niap-ccevs.org/pp/pp_hcd_eal2_v1.0/

Hardcopy Device Protection Profiles | HCD Update – 12th ICCC

U.S. scheme began the process of changing their approach to issuing those PPs as “interim” PPs at EAL2. IEEE 2600.1 was one

Government PP that was not under the direct control of the U.S. scheme. The U.S. scheme contacted the P2600 working group and inquired about changing the base assurance package of IEEE 2600.1 from

Because the IEEE 2600-series PPs were IEEE standards, they could not be changed without revising the standard. In addition, there were copyright issues that made it financially irevise and reissue the standard with a different EAL.

At that time, it was mutually agreed that IEEE 2600.1 could remain as the U.S. Government PP for HCDs provided that the P2600 working group establish a project to develop a new PP in the future when the U.S. scheme’s “tailored assurance” approach was fully defined and employed in other technology areas.

he P2600 working group established a new project authorization request

2010, the U.S. scheme inquired about the differences between IEEE 2600.2 (EAL2) and IEEE 2600.1 (EAL3). The differences are in two areas:

IEEE 2600.1 requires protection of data in motion. IEEE 2600.2 does not.IEEE 2600.1 has auditable events that are not required in IEEE 2600.2. Further, the information to be collected in audit logs is somewhat more extensive in IEEE 2600.1 than it is in IEEE 2600.2.

the U.S. scheme issued a Policy Letter #2011 in which it stated that it will recognized IEEE 2600.2 augmented with changes outlined in that policy as the U.S. Approved PP. The policy letter

protection of data in motion by adding security functional requirements (SFRs) from IEEE not address the additional audit requirements.

IEEE 2600.1 would no longer be accepted for new evaluations in the U.S. scheme. However, products claiming conformance either to IEEE 2600.1 or to IEEE 2600.2 with those augmentations outside of the

plaint with the new U.S. Approved PP (i.e., IEEE 2600.2 plus

The new “U.S. Government Protection Profile for Hardcopy Devices Version 1.0 2009)” was posted12 on the U.S. scheme’s list of approved PPs

olicy #20, and provides links to the original IEEE 2600.2and validation report but not to its certificate.

The old “U.S. Government Protection Profile for Hardcopy Devices in Basic Robustness Environments” has been archived and is no longer available. IEEE

remains in place and can be used.

ccevs.org/policy/ccevs/policy-ltr-20.pdfccevs.org/pp/pp_hcd_eal2_v1.0/

ng their approach to U.S.issuing those PPs as “interim” PPs at EAL2. IEEE 2600.1 was one U.S.

The U.S. scheme contacted d about changing the base assurance package of IEEE 2600.1 from

IEEE standards, they could not be changed without revising the standard. In addition, there were copyright issues that made it financially impractical to

At that time, it was mutually agreed that IEEE 2600.1 could remain as the U.S. Government PP for HCDs future when the

defined and employed in other technology areas. roject authorization request with the

t the differences between IEEE 2600.2 (EAL2) and IEEE

required in IEEE 2600.2. Further, the information to be collected in audit logs is somewhat more extensive in IEEE 2600.1 than it is in IEEE 2600.2.

in which it stated that it will recognized The policy letter

by adding security functional requirements (SFRs) from IEEE

IEEE 2600.1 would no longer be accepted for new evaluations in the U.S. scheme. However, products claiming conformance either to IEEE 2600.1 or to IEEE 2600.2 with those augmentations outside of the

plaint with the new U.S. Approved PP (i.e., IEEE 2600.2 plus

12th ICCC | International evaluation and recognition of HCD PPs 7

International evaluation and recognition of HCD PPsThe current situation for HCD evaluation and recognition of certification has become complex. It is difficult to explain even within the technical community, and even more so to marketing, sales, and customers.

Table 1 - Current Confusing Recognition Arrangement for HCD evaluations

There are two particularly troublesome areas, highlighted in Table 1:

1. Although it is the U.S. scheme’s prerogative to establish national evaluation policies that disallow valuations at EAL3, they have also established a procurement policy that does not fully recognize non-U.S. CCRA evaluations that conform to a PP which was validated in their own scheme. It demotes the evaluated assurance level from EAL3 to EAL2, and ignores the additional audit event and information requirements that have been satisfied by the target of evaluation.

2. It is not clear how the new U.S. PP for HCDs applies internationally, either for evaluation of products or for recognition of certified products. It is a PP that is defined by a validated PP plus additional SFRs that are provided in a scheme policy letter.

How are vendors using the PPs?Many vendors have performed evaluations conforming to the original U.S. PP at EAL3+. Since Policy #20 was issued, some have continued to use IEEE 2600.1 at EAL3, while others have started using the new U.S. PP at EAL2+ for evaluations in the U.S. scheme.

8 How are vendors using the PPs?

Figure 6 shows the number of evaluation projects conforming to any of those PPs since the first one was issued in June, 2009. Figure 7Figure

Referring back to Figure 1, there have been over 75 certificates issued in 2010 and 2011but Figure 7 shows that only eight cerwere issued for evaluations conforming to a PP. Most HCD certificates have conformed only to standalone Security Targets (STs) and not to one of the HCD PPs.

Some vendors are still completing earlier evaluation projects, others have not yet made the transition from standalone STsconforming to a PP, and the trend in shows that most new evaluation projects are for evaluations conforming to a PP.

0

2

4

6

8

10

12

14

16

6/2/2009 6/2/2010

Num

ber o

f eva

luat

ion

proj

ects

Evaluation projects,conforming to HCD PPs

Figure 6 - Evaluation projects conforming to a PP

How are vendors using the PPs? | HCD Update – 12th ICCC

shows the number of evaluation projects conforming to any of those PPs since the first one was Figure 6 shows the number of certificates that have been issued.

, there have been over 75 certificates issued in 2010 and 2011,

certificates for evaluations conforming to a

HCD certificates have conformed only to standalone Security Targets (STs) and

completing earlier evaluation projects, others have not yet made

to STsand the trend in Figure 8

st new evaluation projects are for evaluations conforming to a PP.

6/2/2011

Evaluation projects,conforming to HCD PPs

0

2

4

6

8

10

12

14

16

6/2/2009 6/2/2010

Num

ber o

f cer

tific

ates

Certificates,conforming to HCD PPs

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

6/2/2009 6/2/2010

Evaluation projects

Not conforming to a PP

Conforming to a PP

Evaluation projects conforming to a PP Figure 7 - Certificates conforming to a PP

Figure 8 - Evaluation projects, PP versus no PP

shows the number of evaluation projects conforming to any of those PPs since the first one was certificates that have been issued.

6/2/2010 6/2/2011

Certificates,conforming to HCD PPs

6/2/2011

Evaluation projects

Conforming to a PP

Certificates conforming to a PP

Evaluation projects, PP versus no PP

12th ICCC | What is next for Hardcopy Device PPs 9

Why are some HCD evaluations not conforming to any PP?To understand why some new evaluation projects are being started that do not conform to a PP, an informal vendor survey was taken. Many vendors were not comfortable revealing their reasons or strategy for choosing one PP or another or no PP, especially to this author who is employed by a vendor and competitor. An independent party13 was engaged to perform the survey and sanitize the results. Still, only five vendors responded, and therefore it is an informal survey result:

All five vendors have started or completed evaluated products conforming to IEEE 2600.1 or the old U.S. PP.

Two vendor plan to continue using IEEE 2600.1, which implies evaluation outside of the U.S. One of them said that they prefer IEEE 2600.1 because EAL3 is expected by their customers.

One vendor is using the new U.S. PP (IEEE 2600.2 augmented by NIAP Policy #20). Their reason for this was that it is the only PP that is allowed for evaluations in the U.S.

One vendor said that they may stop using any PP because they are not certain about the market requirement for PP conformance.

Once vendor said that they are concerned about the complication of having two PP standards.

Unfortunately, none of the vendors that are not using PPs responded to the survey, so the main goal of this survey was not accomplished.

What is next for Hardcopy Device PPsA primary objective of the IEEE P2600 working group was to create a PP that could be used by government and enterprise customers worldwide that was adopted specifically by the U.S. governmentand that could be employed internationally for product evaluations. Initially, our objective was fulfilled, but our PPs were published at a time when the U.S. and other schemes were adopting a new “tailored assurance” approach that deprecated the use of EALs and when the CCDB was creating a new vision for Collaborative Protection Profile development.

A PP that is composed of IEEE 2600.2 augmented by additional SFRs specified in NIAP Policy #20 has created a confusing but interim solution. However, its use in some schemes, and continued use of IEEE 2600.1 in other schemes, is likely to continue for some time.

It is unlikely that the HCD technical community will write a new PP until it has gained the practical benefit of actual experience with its current PPs. Despite the confusing situation, the current PPs appear to be working, and it is expensive and time-consuming to create a new PP.

13 Many thanks to Mr. Ray Potter, Founder and Managing Director, Apex Assurance Group, http://www.apexassurance.com, for taking this survey and sanitizing the results for this author.

10 What is next for Hardcopy Device PPs | HCD Update – 12th ICCC

It is possible that Supporting Documents (SDs) could be developed to enhance the existing PPs and begin to meet the objectives of the CCDB’s April, 2011 Vision Statement14 and of Chris Salter’s January, 2011 Common Criteria Reforms15 paper.

Creation of Supporting Documents for HCD PPs has been discussed in the IEEE P2600 working group, in the IEEE-ISTO Printer Working Group, and elsewhere. To help identify what might be included in Supporting Documents for HCDs, the HCD community sought to learn from what is being developed in other technical communities that are producing new “standard PPs” and associated SDs.

Where are the Supporting Documents?Each of the aforementioned papers uses Smartcard technical community and the use of Supporting Documents as benchmarks. Indeed, any discussion of improvements in the efficiency and effectiveness of the Common Criteria almost inevitably includes some reference to Smartcards or Supporting Documents. And yet, none of the recently issued PPs for general purpose IT products, nor those in development, appears to have created or planned to create Supporting Documents.

Instead, we find that new PPs contain detailed functional and assurance requirements, national policy statements, and the future potential of including itemized vulnerabilities, all baked into the PP. Some of the detailed functional and assurance requirements used in one PP are subsequently replicated in PPs for other technology types. Finally, there seems to be a new but unwritten process for evaluating and updating new PPs.

Concerns about level of detailSome areas of the new PPs provide a low level of detail for security functions and related assurance activities. This is especially true in areas that deal with cryptographic operations. While it may be appropriate for such detail to be part of CC evaluation, there are some structural problems caused by providing such detail in the PP itself.

The example in Figure 9 is excerpted from the Network Devices Protection Profile16 (NDPP) Version 1.0. It is an extended component for random bit generation, with an associated application note, assurance activities, and two implementation notes. It is included here not to be readable, but to show the amount of text associated with this single SFR. It spans two and one-half pages in the actual document.

14 http://www.commoncriteriaportal.org/files/communities/2011-04-001%20Vision%20statement%20for%20Collaborative%20PP%20development%20v1%200final.pdf15 http://www.niap-ccevs.org/cc_docs/CC_Community_Paper_10_Jan_2011.pdf16 http://www.niap-ccevs.org/pp/pp_nd_v1.0.pdf


Obfuscation of requirementsAn SFR is a Security Functional Requirement, and this level of detail is likely to obfuscate the underlying requirement that is being placed on the conforming product. It does not help that extended components in this PP were not defined with a rationale for their use, and that this particular PP does not provide a rationale table directly mapping SFRs to objectives in the Security Problem Definition.

Without a clear understanding of its purpose, it may be difficult to apply this SFR and even more difficult to correctly maintain it.

The need for extended componentsDetailed requirements tend to push the envelope of standard CC components, leading the PP authors to use extended components. Widespread use of extended components increases the difficulty of evaluation and decreases the commonality of the Common Criteria.

Built-in obsolescenceDetailed specifications of protocols, algorithms, key sizes, or other implementation details are likely tobecome obsolete more rapidly than the Security Problem Definition or the basic security functional requirements of the TOE.

Indeed, in the example in Figure 9 there is a reference to expected replacement of FIPS 140-2 by FIPS 140-3. While it is useful to include such information in this PP, will this PP be updated when FIPS 140-3and its transition plan are introduced? Will it be updated again at various milestone dates in that transition plan?

In the NDPP, there are at least eight cases of expected obsolescence, each of which may require more than one PP update to adequately document their transition. Unexpected obsolescence, as would occur if for example a hash function is broken, would add additional update burden to the PPs in which such detailed specifications are contained.

Replication of common requirements invites errorThe block of text shown in Figure 9, along with other blocks of text from the NDPP, is replicated in the current drafts of three Enterprise Security Management (ESM) PPs. Detailed requirements are likely to be replicated from one PP to other PPs when they address issues that are common across multiple technology types. Initially, replication makes sense. Ultimately, it is an invitation to copy-and-paste

FCS_RBG_EXT.1 Extended: Cryptographic operation (Random Bit Generation)

FCS_RBG_EXT.1.1 The TSF shall perform all random bit generation (RBG) services in accordance with [selection, choose one of: NIST Special Publication 800-90 using [selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES), Dual_EC_DRBG (any)]; FIPS Pub 140-2 Annex C: X9.31 Appendix 2.4 using AES] seeded by an entropy source that accumulates entropy from at least one independent TSF-hardware-based noise sources.

FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded with a minimum of [selection, choose one of: 128 bits, 256 bits] of entropy at least equal to the greatest bit length of the keys and authorization factors that it will generate.

Application Note: NIST Special Pub 800-90, Appendix C describes the minimum entropy measurement that will probably be required future versions of FIPS-140. If possible this should be used immediately and will be required in future versions of this PP.

For the first selection in FCS_RBG_(EXT).1.1, the ST author should select the standard to which the RBG services comply (either 800-90 or 140-2 Annex C).

SP 800-90 contains four different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used (if 800-90 is selected), and include the specific underlying cryptographic primitives used in the requirement or in the TSS. While any of the identified hash functions (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CT_DRBG are allowed. While any of the curves defined in 800-90 are allowed for Dual_EC_DRBG, the ST author not only must include the curve chosen, but also the hash algorithm used.

Note that for FIPS Pub 140-2 Annex C, currently only the method described in NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms, Section 3 is valid. If the key length for the AES implementation used here is different than that used to encrypt the user data, then FCS_COP.1 may have to be adjusted or iterated to reflect the different key length. For the selection in FCS_RBG_(EXT).1.2, the ST author selects the minimum number of bits of entropy that is used to seed the RBG.

The ST author also ensures that any underlying functions are included in the baseline requirements for the TOE.

Assurance Activity:

The evaluator shall review the TSS section to determine the version number of the product containing the RBG(s) used in the TOE. The evaluator shall also confirm that the TSS describes the hardware-based noise source from which entropy is gathered, and further confirm the location of this noise source. The evaluator will further verify that all of the underlying functions and parameters used in the RBG are listed in the TSS.

The evaluator shall verify that the TSS contains a description of the RBG model, including the method for obtaining entropy input, as well as identifying the entropy source(s) used, how much entropy is produced by each entropy source. The evaluator shall also ensure that the TSS describes known modes of entropy source failure. Finally, the evaluator shall ensure that the TSS contains a description of the RBG outputs in terms of the independence of the output and variance with time and/or environmental conditions.

The evaluator shall also perform the following tests, depending on the standard to which the RBG conforms.

Implementations Conforming to FIPS 140-2, Annex C

The reference for the tests contained in this section is The Random Number Generator Validation System (RNGVS) [RNGVS]. The evaluators shall conduct the following two tests. Note that the "expected values" are produced by a reference implementation of the algorithm that is known to be correct. Proof of correctness is left to each Scheme.

The evaluators shall perform a Variable Seed Test. The evaluators shall provide a set of 128 (Seed, DT) pairs to the TSF RBG function, each 128 bits. The evaluators shall also provide a key (of the length appropriate to the AES algorithm) that is constant for all 128 (Seed, DT) pairs. The DT value is incremented by 1 for each set. The seed values shall have no repeats within the set. The evaluators ensure that the values returned by the TSF match the expected values.

The evaluators shall perform a Monte Carlo Test. For this test, they supply an initial Seed and DT value to the TSF RBG function; each of these is 128 bits. The evaluators shall also provide a key (of the length appropriate to the AES algorithm) that is constant throughout the test. The evaluators then invoke the TSF RBG 10,000 times, with the DT value being incremented by 1 on each iteration, and the new seed for the subsequent iteration produced as specified in NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms, Section 3. The evaluators ensure that the 10,000th value produced matches the expected value.

Implementations Conforming to NIST Special Publication 800-90

The evaluator shall perform 15 trials for the RNG implementation. If the RNG is configurable, the evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that the operational guidance contains appropriate instructions for configuring the RNG functionality.

If the RNG has prediction resistance enabled, each trial consists of (1) instantiate drbg, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. “generate one block of random bits” means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP 800-90).

If the RNG does not have prediction resistance, each trial consists of (1) instantiate drbg, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that the second block of random bits is the expected value.

Figure 9 - Extended component SFR and notes from NDPP


without thinking, to update requirements in some PPs but not others, and potentially to introduce security incompatibilities between different technologies as those common requirements specifications drift apart.

Concerns about national policiesNational policies, driven by intelligence concerns or by procurement issues, are an unavoidable element of CC evaluation. National CC schemes are responsible for conflicting roles: the traditional national security role in which national concerns are top priority, and the CC role in which international cooperation and mutual recognition are key success factors. It is not surprising, therefore, to see national policy statements appearing in PPs like the one shown in Figure 10 that appears in three ESM PPs.

There are many problems with inclusion of national policies in PPs:

1. They should not be expressed as Security Functional Requirements unless they are necessary to fulfill an objective of the Security Problem Definition. What is the threat that leads to mitigation by a national policy?

2. If they are expressed as Organizational Security Policies (and they are essentially organizational security policies), they would need to be satisfied by either TOE objectives or environmental objectives. In this situation, the fulfillment of the objective (I.e., completion of FIPS 140-2 validation) would be a prerequisite to CC evaluation.

3. If they are expressed in Application Notes, they must still be addressed in some manner during CC evaluation. This may still lead to fulfillment of the national policy as a prerequisite to CC evaluation.

4. It is often unclear if the national policy is an evaluation requirement or a procurement requirement. If it is a national evaluation requirement (e.g., if you are evaluating in the U.S. or Canada then you must have FIPS 140-2 validation), then what is its true purpose? If it is a national procurement requirement, (e.g., if you plan to sell your product in the U.S. or Canada, then you must have FIPS 140-2 validation), then how can another nation evaluate such a requirement?

5. Should national policies be included for any certificate authorizing nation? Or for all CCRA participating nations?

If cryptography is internal to the TOE, the evaluator shall verify that the product has been validated by FIPS 140-2 (if evaluating in the United States or Canada) or an equivalent national standard for the nation in which the evaluation is being conducted.

Figure 10 - National policy statement from three draft ESM PPs


Concerns about overspecified vulnerability analysisVulnerability analysis has been left to the judgment of the evaluators, and that remains the case in new PPs. However, the NDPP has a note about future versions as shown in Figure 11. Is the intention of this statement that the vulnerability analysis from multiple product evaluations will be collected andused as tailored assurance requirements in future versions of a PP? If so, there

are several issues:

1. Who will collect and collate the results of multiple evaluations’ vulnerability analyses?2. Product security vulnerabilities are discovered, reported, and fixed. Then new ones are

discovered. This cycle occurs with greater frequency than a basic PP needs to be updated.3. Who will assess and maintain the continued relevance of an itemized list of vulnerabilities to be

analyzed?4. If the list is not updated as vulnerabilities become irrelevant, then developers and evaluators

will be required to do unnecessary vulnerability testing.

To validate the assertion that vulnerabilities come and go more frequently than PPs need to otherwise be updated, a ten year sample of HCD vulnerabilities was taken from the NIST NVD17 and from Secunia18. Of the 564 vulnerabilities reported, 127 were unique. Duplication occurs when one vulnerability is reported multiple times, for different models of a vendor’s product, or when the same vulnerability isreported both in the NVD and on Secunia.

Of those 127 vulnerabilities, occurrences of the top nine vulnerabilities are plotted against the years in which they are reported in Figure 12. As can be seen, some vulnerabilities are no longer a concern (e.g., Buffer Overflow and No Authentication). Others seem to be increasing (Cross-Site Scripting and Crafted Request). Some are not so clear and should be watched (Command Injection and Directory Traversal).

17 http://nvd.nist.gov/18 https://secunia.com/advisories/

For the first generation of this protection profile, the evaluation lab is expected to survey open sources to discover what vulnerabilities have been discovered in these types of products. ... This information will be used in the development of penetration testing tools and for the development of future protection profiles.

Figure 11 - Note about future versions of the NDPP


Figure 12 - Top nine HCD vulnerabilities over time

Therefore, it does appear that at least for HCDs, vulnerabilities appear and disappear more often than it is necessary to update a basic PP.

Concerns about PP update frequencyMany of the aforementioned items of concern make it necessary for the new PPs to be frequently updated. Indeed, one authority in the development of new PPs stated that PPs would be “living documents” and that they would be “frequently updated”. Frequent updates can have unfortunate consequences, especially for vendors and customers:

Even if changes are small, frequent updates disrupt routine and reuse that is possible with a stable and long-lived PP.

Updates for one purpose may, by human nature, be accompanied by unrelated changes. Further, such changes are likely, again by human nature, to add new requirements and not remove old ones.

No longer an issue.

On the rise?

Keep watching.

12th ICCC | A proposal for how to achieve the Collaborative PP vision 15

In cases where common requirements have been replicated across multiple PPs, and update in one PP may not be reflected by a corresponding update in the replicates. This is particularly likely when common requirements are taken from one PP (e.g., NDPP) written by one technical community and replicated in another PP (e.g., an ESM PP) that is written by a different technical community.

Updates with a frequency that is higher than a typical product lifecycle will make it more difficult for customers to compare one certified product against another. Products on the market at the same time may be certified to conform to different baselines. Even if the differences are small, this can weaken one of the key purposes of the Common Criteria from a customer’s perspective.

Concerns about PP evaluation processFrequent updates imply that the formal evaluation and certification process for PPs will be impractical. Already, we are seeing new PPs that are “evaluated and certified when they are first used”. There are at least three problems with shortcutting the PP validation process in this way:

1. It places a significant project risk on the first vendor to certify a product. If the PP is changed, then the vendor may need to deal with rework to conform to the changed PP, possibly in the middle of an evaluation.

2. Certification-on-first-use implies that the first use of a new PP will be performed in the U.S. scheme or its coalition of schemes that are promoting this kind of PP process.

3. Is the quality of a PP evaluation performed on one instance of a conforming ST the same as evaluating a PP in the abstract?

A proposal for how to achieve the Collaborative PP visionThe goal of tailoring PP assurance activities to each technology type makes sense. The need for more detailed implementation specifications has merit. National policies are unavoidable when dealing with national governments. Ensuring that CC evaluations perform analysis of real-world vulnerabilities can only improve the relevance of the CC to customers.

How, then, can these goals be accomplished without overloading the PP with requirements that are too detailed, nation-specific requirements, or transient, resulting in too many updates and inadequate governance of PP certification?

A high-level PP plus some specific, independent, Supporting Documents can accomplish the goals of the new vision for PPs while mitigating most of the concerns expressed in this paper. This approach can be applied to HCDs, but it makes better sense to apply it to multiple technologies.

Start with a high-level PPWhat is a high-level PP? IEEE 2600.1 is a fair example. A sample from that PP which traces from asset to objective to principal SFRs is presented in the next few sections.

16 A proposal for how to achieve the Collaborative PP vision | HCD Update – 12th ICCC

An asset is definedWe defined four categories of security-relevant assets, all of them related to data. Other assets were handled as Organizational Security Policies (refer to the 11th ICCC presentation19 for details). One of those assets is D.PROT, which is TSF data that can be disclosed freely but must be altered only by its owner or by an administrator:

D.PROT

TSF Protected Data are assets for which alteration by a User who is neither an Administrator nor the owner of the data would have an effect on the operational security of the TOE, but for which disclosure is acceptable.

Examples are provided as guidance to the ST author:

Examples of TSF Protected DataUser and Administrator identification dataScan/fax/e-mail destination lists or address booksJob status logsStatus of pending or stored jobs and documentsDevice and network status information and configuration settingsDevice security status

A threat against the asset is describedIt is a minimalist expression of the threat, but it applies to the asset in any situation (at rest, in motion, on disk, in memory, or in the case of HCDs, printed copy in the output tray!).

Threat Affected asset DescriptionT.PROT.ALT D.PROT TSF Protected Data may be altered by unauthorized persons

An objective is assigned to mitigate that threatAgain, the expression is minimal but sufficient for this kind of PP.

Objective Definition

O.PROT.NO_ALTThe TOE shall protect TSF Protected Data from unauthorized alteration.

Simple SFRs satisfy the objectivePrincipally, there are two SFRs: one for data in the HCD and one for data being transmitted outside of the machine. Associated SFRs (not shown here) establish security roles and user identification and authentication.

19 http://grouper.ieee.org/groups/2600/presentations/11iccc/smithson.pdf

12th ICCC | A proposal for how to achieve the Collaborative PP vision 17

Benefits of a high-level PPA high-level PP provides a very clear expression of the Security Problem Definition (SPD) for the TOE. It is also consistent with the intention of the CC. It is “a security specification on a relatively high level of abstraction”20 and “an implementation-independent statement of the security needs for a TOE type” 21.

It can be a stable, long-lived document. The HCD PPs are as valid today as they were when published, one to two years ago. The basic functions of the product have not changed, and therefore, the high-level security problem definition and requirements do not need to change. Aside from changes in the CC itself, they might well have been valid ten years ago. And, aside from changes in the CC (or other influences), they might be valid ten years from now.

What is missing from a high-level PPA high-level PP like IEEE 2600.1 contains no implementation details. IEEE 2600.1 does not even have any FCS-class SFRs, even though cryptography is certain to be implemented in conforming products. There is no guidance about which communication protocols to use or vulnerabilities to analyze or national policies to follow. Assurance of appropriate implementation is left to the judgment of the evaluators and the scheme overseeing the evaluation. This has led some to worry that evaluations are too

20 Common Criteria v3.1 r3, Part 1, p. 89, http://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R3.pdf21 Common Criteria v3.1 r3, Part 1, p. 18, http://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R3.pdf

FTP_ITC.1 Inter-TSF trusted channelHierarchical to: No other components

Dependencies: No dependencies

FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the communicated data from modification or disclosure.

FTP_ITC.1.2 The TSF shall permit the TSF, another trusted IT product to initiate communication via the trusted channel.

FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for communication of D.DOC, D.FUNC, D.PROT, and D.CONF over any Shared-medium Interface.

FMT_MTD.1 Management of TSF dataHierarchical to: No other components

Dependencies: FMT_SMR.1 Security roles

FMT_SMF.1 Specification of Management Functions

FMT_MTD.1.1(a) The TSF shall restrict the ability to [selection: change_default, query, modify, delete, clear, [assignment: other operations]] the [assignment: list of TSF data] to [selection, choose one of: Nobody, [selection: U.ADMINISTRATOR, [assignment: the authorized identified rolesexcept U.NORMAL]]].

FMT_MTD.1.1(b) The TSF shall restrict the ability to [selection: change_default, query, modify, delete, clear, [assignment: other operations]] the [assignment: list of TSF data associated with a U.NORMAL or TSF data associated with documents or jobs owned by a U.NORMAL] to [selection, choose one of: Nobody, [selection: U.ADMINISTRATOR, the U.NORMAL to whom such TSF data are associated]].

18 A proposal for how to achieve the Collaborative PP vision | HCD Update – 12th ICCC

subjective, producing results that are inconsistent from one lab or scheme to another, and therefore, unreliable22.

We can use Supporting Documents to provide the additional details without impacting the high-level PP.

Add a supporting document for Approved Implementation PracticesThis document specifies or recommends the current best practices for implementation of common security functions, such as cryptography, communications, and credentials management. It can include assurance activities that are tailored to those implementation practices. In many cases, this document can be used by several different technology types.

By providing a single source of best practices that can be referenced by name, issues that result from replicating text are mitigated. As an independent document, it can be updated without requiring updates to every PP that makes reference to it. Any extended components that are necessary are contained in the document and do not proliferate in PPs. And, by containing low level details in a supporting document, PPs can remain understandable at a high level.

This document is developed by a combination of experts in the security functions and experts in the CC. It should be reviewed by technical communities to which it applies. The Common Criteria Development Board (CCDB) would have final review and approval. Conformance to this document is conditionally mandatory.

Add a technology-specific supporting document for Vulnerability AnalysisThis document specifies or recommends vulnerabilities to be analyzed by developers or evaluators. It is tailored to each technology type, and based on trends gathered from real-world vulnerability reports. It may also recommend tools or techniques that can be used to aid the analysis.

Instead of relying on each lab that evaluates a product to independently obtain current vulnerability information for a given technology type, this document is developed by the technical community. This eliminates duplication of effort by multiple labs. Every technology type will have a vulnerability analysis supporting document, and conformance is mandatory.

Add one or more supporting documents for National PoliciesThese documents specify or recommend national security and procurement policies for nations or for groups of cooperating nations. Whenever possible, National policies are expressed in these documents in the style of Organizational Security Policies but implemented as Application Notes.

They are developed by the respective nations or groups of nations, and are provided as guidance to vendors who intend to sell their products to those nations. Conformance to any of these documents is therefore optional.

A typical conformance scenarioFollowing this proposal, a product’s Security Target will specify conformance to: 22 So far, there have been no such problems with HCD evaluations.

12th ICCC | Conclusions 19

1. The current version of the high-level PP for its technology type, and that PP requires conformance to:

a. The current Approved Implementation Practices supporting document,b. The current Vulnerability Analysis supporting document for its technology type, and

2. Optionally, one or more National Policies supporting documents.

ConclusionsNew PPs are being developed in a way that overloads PPs. We are trying to have PPs serve too many, sometimes conflicting purposes. Those purposes could be served very simply by creating high-level PPs that are supplemented by supporting documents:

A high-level PP is easier to write, empowering technical communities to collaboratively create PPs that are efficient, effective, internationally recognized, and long-lived.

Addressing other requirements through specific supporting documents provides focus andmotivation for the development of those documents, while reducing conflicting objectives that we find in monolithic PPs.

A supporting document can be updated as needed without impacting PPs or other Supporting Documents.

Applying Supporting Documents to multiple technology types, when that is possible, ensures that necessary updates are applied uniformly across technology types and maintains security compatibility among them.

Placing national policies in guidance documents makes it possible to express those policieswithout violating international recognition of PPs.

Challenging vendors to identify vulnerability trends for their technology type provides uniformity of vulnerability analysis (and could also motivate vendors to fix some bugs).

The overall benefit of this proposed approach is that one large, seemingly intractable problem isdecomposed into smaller, manageable, focused problems that can be addressed by appropriate stakeholders. It is a shorter path to achieving the CCDB’s vision of Collaborative Protection Profile. Perhaps this will motivate CC schemes to focus their efforts on that vision and not dissipate their energies on interim, national solutions.