atsec’s ACVT service is operational

atsec is proud to announce that the Automated Cryptographic Validation Testing (ACVT) service is operational.

The atsec Cryptographic Security Testing (CST) laboratory is the first ever to achieve operational status with the Automated Cryptographic Validation Protocol (ACVP) production server operated by NIST. atsec's ACVP tools are fully implemented and functional. After the test results for all types of algorithm testing offered by the ACVP server were validated by NIST, atsec’s CST lab was granted access to the ACVP production server. atsec performed the algorithm testing on its SHA and HMAC implementations used in the atsec ACVP Proxy, which is the very first ACVT project to demonstrate that the NIST ACVP production server is now in business.

With this privileged access, the atsec new service uses the ACVP production server to automate the process of testing the implementation correctness of cryptographic algorithms and related functions, and offers a much more efficient and effective process in the awarding of certificates by NIST.

Certificates of implementation correctness are awarded by the cryptographic algorithm validation program; these certificates being required as a pre-requisite for cryptographic module validation as well as for Common Criteria evaluations in the U.S.

Mr. Stephan Mueller, one of atsec’s Principal Consultants, has worked closely in the development of the client program to test the NIST ACVP demo server, which has greatly helped NIST’s successful launch of the ACVP production server. He commented on this collaboration between atsec and NIST.

“NIST is to be congratulated on this important milestone in the development of the ACVT program. A program which provides assurances in the security of IT systems implementing cryptography as well as supporting developers by providing the capabilities to test in synch with modern development timescales.”

Dr. Yi Mao, atsec Laboratory Director, also commented.

“We applaud NIST’s initiative in launching the ACVT program and are proud of assisting them in achieving this historically significant milestone. Cryptography is the hard core that provides information security. Automated testing is the way forward to sustain the high demand of the much-needed assurance at the core of security. It’s an extremely exciting moment, and empowered with ACVT, we can immediately benefit our existing and new customers by taking their algorithm validation down a fast path.”

Find out more at:
atsec’s cryptographic algorithm testing service page.
NIST’s Automated Cryptographic Validation Testing (ACVT) project.

Mea Culpa.

Unfortunately, atsec has been accused of distributing fake news.

Here at atsec we take such an accusation seriously. We have performed a thorough internal investigation and have determined that the accusation is true. atsec has been guilty of disseminating fake news on an annual basis for the last fifteen years.

We have followed our internal ISO 9001 and ISO/IEC 27001 conformant procedures, and determined a root cause of the issue.

•  This issue is traditional and widespread. The production of fake news on an annual basis can be traced back as far as 1392, when the first identified written documentation of an annual fake news article was recorded by a Mr. Geoffrey Chaucer.
•  Further research has shown that the practice can be traced back to the Roman and Ancient Greek eras. These civilizations celebrated The Hilaria around the time of the March equinox and this included abstinence form eating pomegranates during this time.
•  Considering atsec’s diversity we identified that the Italians, Germans, Swedes, French, Latvians, Indians, Chinese, Polish, Vietnamese, British, Mexicans, and Argentinians are all taught at an early age the art of providing fake news on an annual basis. 

As additional input, we note that:

•  atsec China since last year is subject to local restrictions on this matter, however this practice has been widespread in China in the past.
•  Germany is considering legislating on this practice .

In consideration of this the following improvements and additional controls are being implemented within atsec and will be strictly enforced.

1. atsec management team will assess the merits of introducing a policy in regard to the production of fake news during the Spring equinox period. Possibly implementing a “no fake-news” policy, enhancing our current internal policies for fake news review. 
2. atsec staff will develop a system to be named the Public Kidding Infrastructure (PKI), which will be based upon defining the roles, policies and procedures needed to help recipients of news determine the integrity index of the news that they are subject to. Information sources will be identified and authorized as part of a trust relationship. In particular, atsec staff will consider the use of blockchain based kidding.
3. atsec proposes and requests support from all atsec associates in defining an internationally agreed fake-news emoji that can be implemented on a wide variety of platforms. As an interim measure, atsec propose the use of Emoji U+1F925 be reserved for this context: 

----------------------------------------------------------------------------------------------------------------------------------------------------

Breaking News: April 1st, 2017......

🤥 **** With immediate effect, any national scheme reports for Common Criteria evaluations above EAL2 will be distributed via WikiLeaks no later than two years after their submission for validation. ****

🤥 **** The successor to FIPS 140-2 will be published in 2017. To avoid conflict with previous drafts, this version will be known as FIPS 140-jalapeño ****

🤥 **** A new Global Protection Profile is being written. This PP will aim to satisfy the needs of security assurance consumers all around the world, and will address all information technologies. Volunteers from the CC community are solicited to serve on the associated technical community are invited to contribute their knowledge and skills in this endeavor ****

🤥 **** A new cPP will be published soon ****

IT Security Issues of Autonomous Cars

Introduction

Over the past decades’ cars have become one of the most complex IT systems. Today each new car has a large number of computer systems interconnected within the car over different bus systems. With the integration of additional assistance systems as required by semi-autonomous or fully autonomous (self driving) cars, the overall complexity of IT systems in the car will increase further as will the requirements for the ability of the car to communicate with cloud services, road-side infrastructure, and other cars.

Communication and its Security Problems

So far the computer systems within the car had only limited connection to the outside world except for their diagnosis interfaces and the interfaces they expose to user devices mainly using Bluetooth -based near field communication technology or direct connection of devices via USB. Some cars also use the cellular network for communication with the workshop or with other centralized systems used for monitoring or for emergency responses. So far cars did not provide the capability to communicate with other cars within their proximity or with the road-side infrastructure (which today usually does not have communication capabilities itself).

With the development of semi autonomous and (later) self-driving cars this will change dramatically. Today the prototypes of those cars rely mainly on the data they receive from the sensors installed within the car. While those sensor systems and the algorithms to derive a view of the car's nearby surrounding get more and more elaborate, there are still significant limitations on what the sensors can 'see' and how fast they can correlate the data to get a complete picture of the situation. What is missing today is a concept for re-using the information gathered and processed by other cars or by the road side infrastructure. Since only a few cars today are equipped with elaborated sensor systems for collecting information from the car's environment, this is not surprising.

Now let us look at a scenario in the (near) future where many (but still not all) cars are equipped with such elaborated sensor systems as well as the capability to communicate with their local environment as well as with centralized systems that can provide the car with useful information. Current developments in the mobile communication world will allow cars to download large amounts of data from cloud services and centralized systems very fast. Cloud services can provide up-to-date map information including information about the traffic situation, street conditions, free parking spots, etc. This information can be gathered from road-side units as well as other cars reporting specific conditions to the cloud services.

The communication link between the car and the centralized systems can be protected using standard protection features offered by the cellular network protocols combined with application-layer security protocols like TLS.

While the general communication security issues for this type of communication can be solved using existing protocols and technology, the situation with car-to-car communication is very different.

Car-to-car communication links are more of an adhoc type where communication partner change rapidly. With some cars, the communication links will be lasting longer (e. g. with cars driving on the same road and in the same direction) while it will be lasting only for a very short time for others (e. g. cars passing by). Especially the cars in front of you may provide very useful information about traffic situations, aspects to watch (like children playing near the road, people that want to cross, other cars trying to enter), their intention (e. g. will brake soon, will turn soon), or about road conditions (e. g. water, ice, or debris on the road) that your sensors can not (yet) 'see' and that the cloud services cannot provide. This information can supplement the data collected by the sensors and thereby enhance the picture of the local situation significantly.

Technically such an adhoc communication network can be established using upcoming technologies like IEEE 802.11p (with IEEE 1609) or LTE ProSe.  In addition, the merging 5G standards will also provide a basis for adhoc networks. Those protocols also provide general security functionality for entity authentication, encryption, and integrity protection. But this is not sufficient for car-to-car communication! You also need to know the exact location of the sender and you need to know that the data is 'fresh'. Even a delay of one or two second in receiving the data may be unacceptable since the data may not only be useless but also dangerous! Those are security issues not addressed by current protocols.

The freshness issue may be easily resolved by a time stamp, but this requires highly synchronized clocks between the sender and the receiver - not a real issue today. The exact location is slightly more complicated but using GPS in correlation with data obtained by the sensors of the car, the location can be determined very precisely and transmitted as part of the data.

While there are emerging standards for the lower protocol levels of car-to-car communication, work needs to be done on the establishment of standards at the higher protocol levels. Interoperability at all protocol levels is key for car-to-car communication at all protocol levels. This is more important than for the communication of cars to cloud services where vendor or vendor group specific solutions may be acceptable.

Security (and Safety) Aspects of IT Systems in the Car

As stated in the introduction, the IT systems in the car have been developed for a closed operational environment. Security was therefore often not a top priority. Those systems also have been quite static with software updates being performed in the workshop only. Adding new applications like it is common in mobile devices was not foreseen and not necessary.

The isolation of the IT systems in the car was broken up with the ability to connect smart phones to the car. Seeing the possibilities Apple (with Apple CarPlay) and Google (with Android Auto) then developed integrated solutions that allow to use the smart phone as an intelligent bridge into the car's navigation and entertainment systems. It is just a matter of time until they also serve as bridges into the more critical IT systems of the car, especially those that collect and correlate the data required for semi-autonomous or autonomous driving.

With the smart phone technology comes greater flexibility, including the ability to install new applications or to update the software over the air.  

Supporting this type of flexibility while also satisfying the strict safety requirements will be the main challenge for the future. The smart phones export quite a number of communication interfaces and their operating systems have reached a level of complexity that allow for the same type of attacks we have seen in standard client and server operating systems over a long period of time. Although iOS and Android allow only for the download of applications that have been signed by Apple or Google, both companies are not able to verify that applications they have signed are free of (intentional or unintentional) security critical flaws. What needs to be prohibited is that those applications can be used as a trojan horse to attack the more critical systems of the car.

To do this the IT systems within the car need to be structured into several criticality levels where levels of higher criticality are separated from the next lower criticality level by some kind of guard system that controls the data transferred between the levels. For example, a guard system protecting a critical system could pass data from the 'low assurance' Android or iOS system to the critical system only if the data as a whole is digitally signed by an entity allowed to communicate with the critical system. The guard system would only verify that the data has a well defined format and is digitally signed. If confidentiality is required the guard system could also be used to decrypt the data. The correctness of such a system can be verified at a high level of assurance and with such a technique the 'low assurance' system can be used just as a 'pass through' system to allow for controlled communication between the critical system and well-defined entities. This is a way that can be used to transport software updates, specific data, and even new applications to the critical system without the ability of other entities within the communication path to interfere with the integrity and - if required - the confidentiality of the data transmitted.

This opens up the possibility to use the smart phones and their technology as a gateway that can easily adapt to new communication protocols e. g. when 5G becomes mainstream. With this concept, the gap between the (relatively short) life time of communication protocols in the mobile world and the (compared to this: relatively long) life time of a car can be bridged.

We have talked about different levels of criticality before. In our model, we see at least three of those levels:

• low criticality: infotainment, navigation data (for use by human drivers) etc.
• medium criticality: connection to roadside assistance services, monitoring performance of car systems and communication with vendor/workshop
• high criticality: sensor systems and the data they collect, navigation data (when used automated navigation in semi-autonomous or fully autonomous cars), critical information received from other cars, any data received from other systems used for automated driving.

As stated before each level should be separated from the others by using a gateway but also by cryptographic means. Cryptography will play an important role for secure car systems. There should be a separate 'master key' for each level (usually the private key of a private/public key pair) as the top of a key hierarchy used for the different application areas within each level. Software updates as well as the installation of new applications would require a digital signature as is already the case in the mobile systems we use. But unlike those systems within the car updates or new applications for the medium and high criticality levels within the car will need a significantly more careful analysis - preferable by an independent third party - to ensure that the software update or the new application adhere to well defined safety and security standards, work as specified and do not misuse the privileges assigned to them. This could be achieved by multiple signatures applied to a software update or a new application where each independent third party applies a signature with the specification of what it has analyzed e. g. the standard used within the analysis, the level of scrutiny (if the standard defines such levels), specific properties looked at during the analysis. Based on those signatures and its attributes the software management within each criticality level can then decide if the update or new application is accepted and what privileges or access to critical functions is allowed.

This could be the basis for a secure IT architecture within a car. To get there, it requires a lot of work to develop the standards not only for communication but also for data structures at the application level and for the general policies of software management within the car. 

By Helmut Kurth

27K: Security Summit for the Americas has started

The 27K: Security Summit for the Americas started off with keynote speeches from David Cannon, Ron Ross and Scott Bullock. The next two days will see presentations from thirty speakers on a wide variety of topics concerning ISO/IEC 27001. atsec information security is represented by Fiona Pattinson, Yi Mao and Helmut Kurth. For more information on the conference, please visit http://iso27001.com.

US partial Government shutdown

The US government shutdown means that the following are affected:

• NIAP - closed until further notice.
  13/10/07 - 

  NIAP Returns from Furlough
  
  As of 7 October 2013, NIAP operations are resumed. Please feel free to contact us with inquiries. We thank you for your continued support.
  

• CMVP (NIST) - closed until further notice, but CSEC (Canada) CMVP 
  will continue operations, however no validations will be completed 
  without a NIST signatory

• CAVP (NIST) -  closed until further notice. 

• SCAP -  closed until further notice.

• GSA and TWIC are also probably affected, 
  but we don't have official word from those programs yet. 

atsec continues to work on IUT and evaluation projects in the atsec labs as normal, but obviously progression through scheme/program milestones may be affected.

atsec customers in evaluation under other schemes such as BSI or CSEC (Sweden) are not being affected. 

atsec customers with questions about their projects should contact their atsec representative. 

7 Shades of Grey

Recently, there has been much discussion about getting away from EAL4 evaluations for complex software, such as operating systems. Instead of applying EAL4 requirements, which include a detailed design description of the implementation, as well as a review of parts of the implementation, the newly discussed approach is to skip detailed designs and source code review and replace it with more elaborate testing.

This new approach effectively turns the security review from a white-box analysis with white-box testing to (almost pure) black-box testing.

We have to face the uncomfortable truth that modern operating systems are so complex that simply by looking at the interfaces, it is hard to understand what is going on in its guts. Just to provide some numbers to illustrate the problem: The entire source code tree of the Linux kernel is about 120 MB in size. Now, let us subtract three quarters from it which provides device drivers and architecture specific code for architectures we are not interested in. We still have then about 30 MB of code covering the higher level functions that are typically assessed in a security evaluation (I am not saying that we skip device drivers in an assessment, but let us make it easy for the sake of argument). In addition, consider that there are about 350 system calls, three important virtual file systems, and some other interfaces to the kernel. Now, do you really think you can test these limited numbers of interfaces to identify what 30 MB of code does with respect to the security behavior?

Well, I have to admit that I cannot.
 
During my work as a lead evaluator in different operating system evaluations and recently supporting the preparation of detailed design documents around Linux, I learned that access to source code and detailed design makes it easy to determine the areas to focus on during security assessments. Even when the new evaluation approach is enacted, I will surely use source code for the assessment to answer questions -- simply because it is there and it gives you the most precise answer.

For closed source products, the proposed evaluation methodology will lack the possibility for the evaluator to consult source code. Therefore, one can argue that the new evaluation methodology is (intentionally?) hurting vendors of closed source products because the evaluation result may not be as thorough as open source evaluations.

Apart from using design and source code to aid security evaluations, we need to ask whether black-box testing is really helpful for security assessments at all. Black-box testing focuses on testing the proper functioning of certain mechanisms. This is also one goal of security assessments -- so black-box testing and security assessment have one commonality. However, there is another goal security assessments have to answer: Is it possible to bypass or tamper with security functions? Do you think that any documentation of external interfaces explains, or the testing thereof shows whether (let alone how) to bypass or tamper with functions? Maybe you can use fuzz testing to find a "smoking gun" hinting at such problems, but you will not be able to really find a conclusive result to the bypassing and tampering problem.

There is another aspect worth mentioning: It is very hard for developers (and even harder for evaluators) to identify all interfaces to, say, the kernel. The prime example is the IOCTLs in a Unix kernel. Without the ability to look into the code, how can an evaluator be sure that all interfaces have been identified and tested? Any black-box approach will seriously fall short of identifying and covering all security-sensitive interfaces.

Of course you can use the binaries, disassemble it and apply black-hat style assessments to find and exploit deficiencies if you do not have access to design and source code. But that approach is not covered with the newly suggested evaluation approach either.

My current verdict to the newly suggested approach can be summarized as:
Trying to perform a security assessment using a black-box approach will result in a failure to achieve the intended goal. To state it differently, you do not expect airplane inspectors to just check if a plane looks nice, check if it has wings, flaps, and other stuff necessary to call it a plane - and then just do a few flights -- the inspectors will look at the internals of the plane in detail, and they do that for a reason -- is this reason so different from our reasons?

Stephan Müller

Lead Evaluator, atsec CC laboratories

Deep Thought on PPs

Encouraged by Helmut's results from his visit to the oracle at Delphi, and having some questions of my own about PPs, I too petitioned for a trip to visit the oracle. Alas, atsec's travel budget is not infinite and I was encouraged to find a similar service closer to home.

Putting my thinking cap on, I decided to consult with Deep Thought. This amazing system is renowned for giving highly accurate answers, no matter the quality of the question, and access to its design team is available in almost every part of the world. So I sent my son to rummage behind our compost heap to bring forth the mice for further evaluation of this system and what assurance I could gain about the security functionality.

The mice stated that an evaluation of Deep Thought using the CC is planned but is currently awaiting the development of a suitable cPP by the Golgafrinchan Technical Community (GTC), who are currently studying information on this kind of evaluation.

Well, regardless of that, I do have some questions about PPs that I feel should be based on objective analysis of information rather than subjective means. This is especially important because the whole community is currently focusing their efforts on PPs. Some examples of questions are:

• Has the proportion of evaluations claiming PP conformance changed over the years?
• How many PPs on the CC portal have not been claimed in an evaluation listed on the CC portal?
• Are any evaluations listed on the CC portal claiming compliance to PPs that are NOT listed on the CC portal?
• Which technology areas tend to use PPs more than others?
• Which are the top 25 most claimed PPs?
• How many PPs have been claimed in a listed validation report only once?
• What is the meaning of life, the universe and everything?

So, the mice allowed me to pose these questions, and I was rewarded by a response from Deep Thought:

"The answers to all of these questions are on the CC Portal." 

Accordingly, I went to the CC portal and downloaded the publicly available CSV files about PPs and  the various certified products that are listed there. I reviewed the CSV files and discovered that the information I needed was not there! True, some PPs are listed in the CSV files, but the information was not there for earlier years and later information is far from complete and is sometimes even incorrect.

I asked Deep Thought, "You said this information was on the portal, but it is not of useful quality. How could you give me such a misleading answer?" Deep Thought replied: 

"The answers are on the CC Portal." 

The mice explained "These things take time. Just as Slartibartfast spent many aeons detailing the low level design of our next generation system for our proposed evaluation of The Earth, including the fjords and the crinkly bits, so you need to read every single validation report on the CC portal. It's a trivial task - there's not so many of them. Only a tad under 2000 of them."

So having great respect for the mice and for Deep Thought I did exactly that. Slipping a babel fish in my ear to help with my comprehension of a multitude of languages, I began the process using the following method.

Method for analysis of PP conformance claims in validation reports listed on the CC Portal

1. First I retrieved the summary CSV files from the CC portal (This was done on 2012/09/24).
2. Next, I combined the PP and archived PP files into one spreadsheet and similarly combined the data for the certified products and archived certified products into one spreadsheet.
3. Then I download every validation report related to the certified products and reviewed each validation report for PP conformance claim statements. In a few instances, the validation report was not available or corrupt, so in this case I reviewed the Security Target for claims.
4. Where multiple PPs were claimed, I duplicated the relevant entry in the CSV file to allow for a one PP per line claim and marked each claim with a "claim number."
5. I updated the new certified products CSV file, adding and correcting the PP claim with the information found by reviewing the validation report.
   
   In many cases the Portal file contained a name for a PP that is apparently an identifier that is of publicly undefined origin, and didn't match the identifier cited in the validation report, so I  added a new column to note the validation report identifier, as well as the CC Portal's identifier. For example, a PP cited in the validation report as BSI-PP-0002-2001 was given in the portal file as SVGPP01.
   I resolved any errors, omissions as best as I could. For example:
   
   • The portal reference "JSPP" could refer to  either  the JavaCard System Standard 2.1.1 Configuration Protection Profile, Version 1.0b or the one for the JavaCard System Standard 2.2. In this case, I modified (and added) the Portal name to include the version.
   • In some cases the Portal reference was not consistent. For example:
     
     • The SECURITY_IC_V1.0 is confused with a ref to what should be SVGPP01;
     • SVGPP01 and  SVGPP refer to the same PP; 
     • Both IEEE Std. 2600.1™-2009 and  PP_HCD_BR_V1.0 refer to the same PP. 
     I corrected these in line with the contents of the validation report.
   • In many cases the PP conformance is not listed in the Portal CSV file at all. In these cases I added the conformance claim to the CSV file.
   • In some cases the date of the PP in the certification report (sometimes called a "validation report") and the date of certification of the PP on the portal do not match by a long way. When no version or date was given in the validation report, a best guess was made.
6. Identify PPs claimed in a certification report on the portal that are not listed on the portal and add them, marking them as "not on the CC portal" in the CSV file.
7. Review the file and look for inconsistencies and attempt to resolve them through further reference to the validation reports, STs, or scheme PP lists as appropriate.

Best practices/improvements for citing PPs

As a result of this process, I devised some recommended best practices for certification bodies when preparing their certification reports. Of course some schemes already do follow these practices, but it is not the case that all schemes do so. Of course we have a problem of historic information  where it is not reasonable to update validation reports retrospectively. This is especially true  for reports related to archived products.

1. State PP claims clearly and concisely in the validation report. Include versions of the PP (even if there is only one version now, another may come along later) and PP certification date (where available).
2. If there is no PP claim, state that fact in the validation report. Just not mentioning PPs at all leaves one wondering if that information is buried in the document somewhere.
3. If a PP claim is made in the validation report state clearly if it is strict conformance or demonstrable conformance that is claimed. (Note that these conformance definitions first appeared in R3.1 of the CC. Before this PP conformance should be of the "strict" type.)
4. Clearly distinguish between a "complete" conformance claim and PPs that were used as reference, or which are partially claimed.
5. Even when a PP is updated, it is important to keep the previous versions for reference. This is especially true when certified products have made claims to that version. Removing an older version of a PP means that it is impossible to properly understand the claims made for that product.
6. Review the process for updating the CSV files on the CC Portal. Could the information being submitted about reported product evaluations or the processing of the information provided be improved? 
7. Review the requirements for the PP registry, including:
• The scope of the register (For example should all PPs, even if they are not used under the CCRA, certified  or packages be listed?);
• Management requirements and processes for operating for the register;
• The structure of the database and the types of information that are summarized;
• The method for allocating of a unique identifier to each PP in order to allow distinguishing PPs with the same or similar names from becoming confused and to identify equivalency between the same PP that has been certified under different national schemes.
• There currently seems to be a mixture of nomenclature methods in use to identify a PP. These include using the full text name, a common (CC portal issued?) identifier, a national scheme identifier, and the validation report number. None of these methods used alone uniquely identify a PP.   

  8.  Validate PPs before using them. 

Some of the detailed PP Questions answered:

Has the proportion of evaluations claiming PP conformance changed over the years?

The data shows that since 2001 the percentage of evaluations that do not claim conformance to any PP has remained between 50-60%.

Data before 2000 was omitted due to the low number of evaluation projects.

Certificate maintenance projects were not included in the data.

How many PPs on the CC portal have not been claimed in an evaluation listed on the CC portal?

Total Number of PPs listed on the CC Portal: 228

Total number of PPs on the CC portal that have been mentioned as claimed by one or more validation reports: 53
This would suggest that only about a quarter of the PPs listed on the CC portal have been used in an evaluation that is also listed on the portal.

Are any evaluations listed on the CC portal claiming compliance to PPs that are NOT listed on the CC portal?

Yes, I found 14 certified product listings  that claimed a PP that is not currently listed on the CC Portal. Some were certified PPs. These PPs are:

PP Ref ID	Name	Certification Date
ANSSI-PP/0304	JavaCard System Standard 2.1.1 Configuration Protection Profile- Version 1.0b	8/1/2003
BSI-CC-PP-0020-V3-2010-MA-01	Protection Profile for electronic Health Card (eHC)- elektronische Gesundheitskarte (eGK)- Version2.9- 19 April 2011	4/19/2011
BSI-CC-PP-0056-2009	Protection Profile for Machine Readable Travel Document with 'ICAO Application'- Extended Access Control- Version 1.10	3/25/2009
BSI-CC-PP-0057-2010	Digital Tachograph - Vehicle Unit (VU PP) version 1.0	7/13/2010
BSI-PP-0030-2008	Schutzprofil PC Client Specific Trusted Platform Module TPM Family 1.2; Level 2; Version 1.1
NIPS_PP_V1.0	Network Intrusion Prevention System Protection Profile- Version 1.0	12/21/2005
PP_CIMC_V1.0	Certificate Issuing and Management Components (CIMC) In Basic Robustness Environments V1.0	4/27/2009
PP_CIMC_V1.1	Certificate Issuing and Management Components Protection Profile- Version 1.1	12/27/2001
PP_FW_AL_BR_V1.0	U.S. Government Protection Profile for Application-level Firewall in Basic Robustness Environments- Version 1.1
PP_FW_TF_MR_V1.2	U.S. Government Traffic-Filter Firewall Protection Profile for Medium Robustness Environments- Version 1.2	1/30/2009
PP_PKE_V2.8	U.S. Government Family of Protection Profiles for Public Key-Enabled Applications for Basic Robustness Environments- Version 2.8	5/2/2007
PP-ACSE	Application de crΘation de signature Θlectronique	2/15/2005
PP-FW-KR_V1.2	Firewall Protection Profile for Government V1.2 (2006. 5.17)
PP-FW-KR_V2.0	Firewall Protection Profile V2.0

Which technology areas tend to use PPs more than others? 

The  use of PPs in the defined technology areas should be further analyzed. Perhaps it is necessary for the CC community to focus on some technology areas, or that existing PPs are de-facto cPPs and change might bring a risk of disruption in that area?

How many PPs listed have been claimed in a listed validation report only once?

Interestingly, the answer to this question is 42.

Which are the top 25 most claimed PPs?

In this analysis, any certificate maintenance activities for a product certificate were not included.

In the light of the new CC MB led technical communities, it's interesting to review the provenance of these PPs, which I am classifying below according to certain characteristics. I pay particular attention to the smart card technology area because this is widely held as a model for future technical communities.

General technology-area  (Smart cards)

The Smartcard IC platform PP V 1.0 (BSI-PP-0002-2001)  often referred to as SVGPP01_V1.0 was provided by a group of 4 smartcard vendors working under the auspices of an organization called "Eurosmart." It was certified by the German BSI scheme in 2001 and is still an active PP. It claims to be based on ANSSI PP/9806 and the Smartcard Protection Profile of the Smartcard Security User Group; SCSUG, Draft Version 2.1d, March 21, 2001.

ANSSI PP/9806 was certified by the French scheme, ANSSI in April 1999 and was claimed in evaluations between 2000 to 2007, with a couple of evaluation claims in 2008 and one in 2010. According to the link to the PP given on the portal  the PP was issued in September 1998 and is the work of a group of 5 vendors. No mention of a user group or organization is made. It is still an active PP on the CC portal but is no longer listed on the ANSSI website for PPs (ANSSI's archived PP page was not working at the time of writing).

The Security IC Platform PP V1.0 (BSI-CC-PP-0035-2007), sometimes known as SECURITY_IC_V1.0, was written in August 2007. The authors are cited as 5 vendors and the PP was certified by BSI. Its basis is claimed to be BSI-PP-0002-2001 and it is not archived status on the CC portal.

The other smartcard related PP on the list with product  evaluation claims is the JavaCard System Standard 2.1.1 Configuration Protection Profile (ANSSI-PP/0304) sometimes known as JCSPPC-2.1.1. This PP is not listed on the portal, although it's predecessor (V1.0b) is. According to this predecessor PP, the main input for this PP came from a single vendor, but what may be the latest version, version 3.0 (May 2010) was reviewed by the Java Card Forum – Common Criteria Subgroup.

This analysis of the general smartcard related PPs revealed that the most claimed PPs are developed by vendors, and that a lab (ITSEF) is engaged as editor of the PP. All are certified PPs by European schemes and a vendor group organization is involved in the PP development. Interestingly these groups are regional in nature, Eurosmart and the Java Card Forum in Europe. Interestingly no PPs that have been claimed in a product evaluation have emerged from the U.S./Latin America focused group, The Smart Card Alliance, nor from the Asia Pacific Smart Card Association. Eurosmart produced a survey of PPs relevant to the smartcard sector, the last version was made in July 2010. As an interesting side note, the Smart Card Security User group's  SCSUG PP V3 appears on the CC portal 4 times. One for each time it was validated and certified (France, Germany, U.S. and Canada) but was never claimed in an evaluation listed on the portal. According to the PP, the SCSUG were comprised of credit card companies (security assurance consumers) as well as the U.S. organizations, NIST and NSA. This class of PPs is perhaps the one best described by the vision for cPPs and the associated technical communities.

The PP for hardcopy devices, PP_HCD_BR_V1.0 was developed through  the IEEE and published as an IEEE standard. It is marked as archived on the CC portal and the U.S. CCEVS also falls into this class.

It is worth noting that the initial IEEE PP was superseded by a U.S. Government approved interim PP based on the IEEE version but that has been modified to meet the U.S. Government policy for low assurance. A CC MB sponsored technical community is working on a new PP for this technology.

Smart card (technology area) specific applications

This group of PPs are aimed at smart card applications, such as digital signature, machine readable travel documents and electronic health card. All have been certified by Germany's BSI.

• BSI-PP-0005-2002, and BSI-PP-0006-2002, Protection Profile - Secure Signature-Creation Device (Type 2 and Type 3): These PPs were  prepared for the European Electronic Signature Standardisation Initiative EESSI by CEN/ISSS area F on secure signature-creation devices (SSCDs). "The document is for use by the European Commission in accordance with the procedure laid down in Article 9 of the Directive 1999/93/ec of the European parliament and of the council of 13 December 1999 on a Community framework for electronic signatures as generally recognised standard for electronic-signature products in the Official Journal of the European Communities."
  In other words, the PP  describes the requirements of  regional international legislation.
  
• Machine readable travel documents for passports (BSI-_PP-0026-2007, BSI-PP-0017-2005 and BSI-CC_PP-0056-2009): These PPs were sponsored by a government organization (Germany's BSI) and drafted by a laboratory (ITSEF). They are based on the requirements and recommendations of the International Civil Aviation Organization (ICAO) and addresses the advanced security methods Basic Access Control and Extended Access Control given by ICAO.
  In other words, the PP  describes the requirements of international regulation.
• PP for electronic Health Card (eHC) - elektonische Gesundheitskarfe (eGK), BSI-PP-0020-V2-2007-MA02. This PP does not appear on the portal but is listed on BSI's website. The PP defines the security objectives and requirements for the electronic
  Health Card (German: “elektronische Gesundheitskarte”) based on the regulations for the
  German health care system. The PP was sponsored by the German ministry of health and drafted by a CC laboratory (ITSEF).
  In other words the PP describes the requirements of national legislation.

Translations of  criteria models existing before CC

The Controlled Access Protection Profile, PP_OS_CA_V1.D, (CAPP), Labelled Security PP, PP_OS_LS_V1.b, (LSPP), and PP-RBAC_V1.0 (RBAC) PPs were widely used in operating system evaluations, as well as occasionally in other technology areas with functionality relevant to this PP class (e.g., database). These PPs were derived from the requirements of the U.S. Department of Defense (DoD) Trusted Computer System Evaluation Criteria (TCSEC), dated December, 1985, and in the case of RBAC from the Federal Criteria. In other words they were translations from existing criteria as the Common Criteria were established. They are largely no longer used and are marked as archived in both the CC portal and the US CCEVS, although they are still listed as active in some other national schemes.

National policy PPs

Several other PPs appear in the top 25 most used PPs that are embodying national policy. 

U.S. Government PPs appearing in the list include a PP for Intrusion Detection Systems, PP_IDS_SYS_BR_V1.7, the U.S. Government PP for Application-level Firewall (Basic Robustness) PP and the U.S. Government  PP for Database Management Systems (Basic Robustness) PP_DBMS_BR_V1.2, and a PP for Peripheral Sharing Switch (PSS) For Human Interface Devices, PP_PSSHID_V1.2. The background for these PPs lies in the U.S. IA policy. These PPs were well used but have been recently retired in favor of those that meet the current U.S. legislative and regulative policies, mainly for the DoD. Originally developed by the U.S. Government in order to specify security requirementsfor COTS products the U.S. has begun developing newer PPs that meet the new policies through NIAP led technical communities. (These NIAP led TCs are distinct from the CC MB led TCs.) It is unclear to me if this method of PP development is an attempt to ensure that the developers' stakeholder voices are heard during the development of such policy and the related PPs.

Also in this class of PPs is Network Intrusion Prevention System Protection Profile, KECS-CR-2004-04 specifying an EAL 4 level of assurance. This PP is not available on the CC portal nor on the Korea national scheme PP list. However, the certification report reveals that both were written and sponsored by the Korean Information Security Agency (KISA).

Others

These include a PP for hardcopy devices, PP_HCD_BR_V1.0, which was developed through  the IEEE and published as an IEEE standard. It is marked as archived on the CC portal and by the U.S. CCEVS. 

The latter mention that it is superseeded by an U.S. Government approved PP based on this PP but that has been modified to meet the U.S. Government policy for low assurance. A CC MB sponsored technical community is working on a new PP for this technology.

We also see a PP named "Oracle Database Management System, PP_ODMS_V2.1, which was developed by a single vendor and has been used only by that vendor. It is worth noting that this is a historical case and that lately other PPs for that technology have been developed that have been used by other vendors, as well as the original vendor in the database technology group.

Discussion

I suggest that there are PPs that have emerged from several different types of communities. From generic technology PPs (such as what we see in the smart card industry) that are often developed by the vendor community at large, through those that specify the requirements for security found in broad regional legislation or industry regulation on a multinational basis to a means for specifying policy for a distinct stakeholder group. In some cases, a single vendor leads the field in developing an initial PP which can later broaden into a wider community. For some of these classes it is appropriate that wide representation from industry is made, but I contend that this may not be necessary for cases where existing legislation, regulation or policy is being translated into the language of CC. In these cases experts on the policy/legislation/regulation are needed alongside experts in the CC. Only if there is room for requirements negotiation is it necessary to have vendor representation.

Apart from some of the more recent U.S. PPs, it has been seen as best practice to have a national scheme certify a PP and it would also seem to be best practice to have an expert in CC draft the PP.

In other words, it is important to understand the high-level goals of a PP before specifying and pulling together an appropriate technical community.

What is the meaning of life, the universe and everything?

The answer is 42. However, one should note that it is vitally important to ask the right question.

The information file, derived from the published on the CC portal and updated with the PP data from the published validation reports, is made available to the CC community, with no conditions. This will hopefully enable my colleagues to answer their own questions. {MD5: 0b238e3d51bcc4663a91a0affe568809 , SHA256: 5312218c9db3c96225f728af614489934812166fea288532f45613689864c140)  However, please note that  I make no guarantees or warranties about the file or the information within it save that I used my best endeavors to prepare it accurately given the information sources available to me.

Conclusion

I have done my best to present the information about PP usage in a way that will enable the community to ask and answer questions about PPs in a more objective way. It is my hope that analysis of the information will enable informed consideration of the proposed cPP, technical communities, vision statements and scheme policy makers. 

Already, in this brief analysis I have shown that that the information can help ask and perhaps even answer some key questions relating to the use of PPs. That if we consider the classes of PPs, those purveying vendor-led minimum security functionality vs those enacting policy, regulation or legislation then we immediately see that the make up of a technical community must vary. For the former we might consider the "end user" to be those consuming the information assurance offered by vendors, i.e., those in the commercial sector as well as in government space. For the latter, the end user is in fact the COTS product developer who must ensure that the cited functionality and assurance is in place for their products. So including the end user in a technical community requires an understanding of who that end-user is. For some PP developments it may not be necessary to include an end user.

I believe that the information also shows the need for a very careful consideration of a PP registry, and the management and parameters of the information recorded. National schemes vary in the way in which the PP records are maintained and the CC Portal has not done a fantastic job in collating the data over the years. I would respectfully suggest though that as we move to the use of cPPs and consider the CC MB vision statement that we also consider what information and records we need now and in the future. As PPs are produced answering national, regional or other needs and cPPs are also produced, how we refer to these and keep track of them is very important in comprehending the assurance provided by product evaluations. This work supports the comments made in Double Vision by Sal la Pietra that the CC MB vision statement needs some informed refinement and by Helmut Kurth in Collaborative PPs in which the need for much enhanced guidance on the topic of PPs from the CCMB/CCDB is sorely needed.

By Fiona Pattinson

Collaborative Protection Profiles and the Oracle of Delphi

We have heard a lot about this idea of “Collaborative Protection Profiles” from the CCDB/MC in the last months. They are mentioned as the most important part of the vision statement recently issued by the CCMC. This vision statement focuses on the management of those Protection Profiles and their use within the CCRA rather than on the development of such Protection Profiles.

The development of such Collaborative Protection Profiles is left to Technical Communities, but very little guidance on the objectives for the development of Protection Profiles, their content, their harmonization, and the process to analyze them has been provided so far by the CCDB/MC.

So I decided to look for ancient wisdom on the subject and went to Delphi to consult the mysterious oracle about the objectives and principles of PP development, as well as the general structure of PPs and how they should be analyzed. I got answers to my questions that I found very useful, and therefore I want to share them with you. May be the oracle should be used more extensively in the cPP development?

Here are my questions and the answers I got:

Q: Oracle, my first question is: what is a Protection Profile?

A: A protection profile is an abstract specification of the security aspects of a needed IT product. It is product independent, describing a range of products that could meet this same need. Required protection functions and assurances must be bound together in a protection profile, with a rationale describing the anticipated threats and intended method of use.

Q: When shall we develop a Protection Profile and who shall be involved in the development of Protection Profiles?

A: Consumers or producers within the Government or the private sector develop protection profiles in response to a specific need for information protection. Profile developers, or sponsors, with a unique security need could propose a protection profile for that need or, more typically, groups of sponsors having similar needs could combine to propose one profile that meets their common need. Multiple sponsors supporting a single profile is an effective way to demonstrate a larger market to potential IT product producers.

The protection profile is intended to respond to both the pull of consumer needs and to the push of advancing technology. Ultimately, the protection profile is a common reference among consumers, producers, and evaluators.

Q: In general, what should a Protection Profile contain?

A: The requirements for protection functions, development assurance, and evaluation assurance must be incorporated into a protection profile. These requirements, specified by the rated functional and assurance components, provide the basic building blocks for the definition of a protection profile. The components must be assembled into a consistent and coherent set that satisfies specific security goals of the anticipated environments of product use. The assembled components should counter expected threats, eliminate vulnerabilities, support security policies, and satisfy regulatory requirements defined in the anticipated environments of use.

Q: Can you be more specific about the evaluation assurance requirements?

A: The Evaluation Assurance Requirements section specifies the type and intensity of evaluation to be performed on an IT product developed in response to a particular protection profile. In general, for an IT product, the scope and intensity of evaluation vary with the expected threat, intended method of use, and assumed environment as defined by the profile developer in the rationale section.

Q: What are the criteria for vetting a Protection Profile and how shall a Protection Profile be validated?

A: After a protection profile has been developed by a sponsor, it must be analyzed.

The goals of protection profile analysis are to ensure the following characteristics:

1. Technical soundness. The elements of a protection profile are technically sound and reasonably balanced, considering the profile rationale (threat, usage, and environment assumptions), and the functional and assurance requirements.
2. Usefulness. IT products built to meet the requirements of a protection profile will serve a useful purpose.
3. Evaluation capability. Implementation of a protection profile’s requirements can be evaluated. Consumers, evaluators, and producers will understand how to determine that the profile requirements have been met by a specific IT product.
4. Distinctness. The protection profile is distinct, in that it does not duplicate a need adequately described by another profile.
5. Consistency. The protection profile is consistent with other profiles in form and level of detail.

Therefore, achieving profile acceptance will often require iteration as the initial profile is refined. Profile revision and analysis continues until an acceptable profile results.

Q: Can you elaborate more on “Usefulness”?

A: Consumers and producers may determine the usefulness of a profile based on different criteria. Determining the profitability of a market is clearly a producer’s responsibility. The protection profile analysis is not intended to interfere with the producer’s business decisions. Usefulness analysis relies primarily on the rationale section of the profile to express the need with respect to threat, usage and environment assumptions.

The analysis also includes an assessment of development feasibility. Protection profiles requiring research and development efforts should be identified so that the profiles will not raise expectations for near-term implementations.

Questions to be answered during the usefulness analysis might include the following: Does this protection profile address a real problem? Does this protection profile differ significantly from existing profiles, or could the needs described in this profile be met adequately by another existing profile? If the demand is too small to support commercial off-the-shelf products, what factors could induce producers to develop products for a niche market? Approximately how large is the demand for these products? Is the protection profile readily implementable? Is the state of technology sufficiently developed or is basic or applied research and development necessary?

Q: Can you be more specific on “Evaluation Capability”?

A: The protection profile requirements must be reviewed to ensure that IT products intended to satisfy the requirements in the protection profile are capable of being evaluated. A protection profile may be used as the basis for product development. The evaluation capability analysis of the profile can pay off by clearly defining what is expected during the evaluation process. As far as possible, requirements in the protection profile should be stated in objective terms so the producer and the evaluator will be more likely to agree on their interpretation of the requirements. If certain requirements must be stated in subjective terms, clear and explicit guidelines should be presented to explain what factors should be considered to determine whether the requirements have been met. Requirements should be simple, declarative statements and for ease of reference, requirements should be numbered or otherwise indexed. These features will help to ensure that requirements will not be overlooked, either during product design and development or during evaluation.

The oracle also indicated that beside those general principles it could provide significantly more detailed information about the functional and assurance building blocks that can be used to develop Protection Profiles. It seems that the idea of Protection Profiles developed by Technical Communities (or “groups of sponsors” as the oracle defines them) existed already in ancient times.

My mysterious ancient Delphi oracle is actually a single document. Not really from ancient Greek time, but still quite old when it comes to Information Technology and evaluations. It was published before the Common Criteria even existed!

This shows that the idea of Protection Profiles developed in a collaborative way that combine functionality and assurance requirements for specific product types has been around since quite a while – and the document most likely provides a better basis for developing Protection Profiles than any guidance the CCDB has provided so far on this subject.

Now the question to the reader: what is this “ancient” document that contains the text passages I have cited above and when was it published? 

I will send a copy of the document to the first one that provides the correct answer.

By Helmut Kurth, Chief Scientist and US Lab Director

Double Vision

Every year, we attend the International  Common Criteria Conference. The most recent  was last week's 13^th edition held in Paris. This conference is one of the highlights of our year. 

We meet our customers, hear from the national schemes, rub elbows with the key players in the industry, keep tabs on our competitors, and listen to the ideas and thoughts that are brought to the community. Not only do we listen, but we try and provoke thought too.

atsec is engaged in an industry that is both founded upon and relies upon mutual trust and reputation. Where professionalism, respect, and a common bond meld together in supporting the developers of COTS IT products demonstrate the independently assured security functionality of their products to a variety of end-users including government, critical infrastructure, and commercial sectors. These products are the front line in protecting the assets of the end users; be they governments, part of critical infrastructures, financial sector, commercial organizations, or the general population. Anyone  that  builds their cyber defenses relying on COTS products demands assurance about the security functions that are claimed.

As we listened to the plenary opening, we heard an exciting “hot off the press” announcement: The CC  Management Committee's vision statement detailing a framework for managing and agreeing collaborative Protection Profiles (cPPs). It seems that after several years the international Common Criteria Recognition  Arrangement (CCRA) will be updated soon. 

Progress at last?

For some years the audience of developers, schemes, and labs have been searching for the next step, and at last now it is here. With the application of agreed upon cPPs, many of the issues and problems associated with using evaluation assurance levels, EALs, as the basis of recognition will be solved. This is good news but it is not yet in effect. Unfortunately we were treated throughout the conference to presentations and discussions that seemed to treat the announcement as if it is fact.

Article 14 of the CCRA demands a full consensus by participants before a change to the Arrangement can be made. While it was not shared if this means the participants that are noted in the last published version of the Arrangement or the CCRA members, including both authorizing and consuming nations that are given on the CC portal's web page. Whatever the constituency for approval is, we were informed that two nations have disagreed with the sections of the proposed vision statement, which allude to  amending the CCRA in order to limit the mutual recognition of certificates for evaluations that do not claim conformance to an agreed cPP to EAL2. The MC proposes additional workshops to help achieve full consensus, but the presentation of the framework as published last week cannot be sure. Given the normal difficulty in achieving full consensus amongst nations, this may take some time.

The risks involved in presenting the vision statement to the community as if it is a “done deal” are immense. The framework will surely need some amendments. Upon review some very obvious issues with the framework are apparent. The agreement process is far from transparent  and there is no call for review by stakeholders other than the MC, so the  MC risks the reputation and trust that has been built in the CC model over more than a decade. Something that affects ALL the stakeholders, not just the members/participants.

By the end of the conference, the MC seemed to have realized that the vision statement was being perceived as already effective and in the closing, found it necessary to stress that nothing had changed yet and that the current agreements and policies are still firmly in place.

By Sal La Pietra,  President & CEO

P.S. For those who were not at the conference you can see our presentations and our humorous clips on our web site.