Yi Mao's Opening Speech at the Fifth ICMC

Dear Community,

It is the second time that I have had the honor and pleasure to open the International Cryptographic Module Conference. This year is very special since it is the fifth anniversary of the conference. 

I’d like to welcome you all with an image from the end of the 1^st ICMC. Many of you may still remember that we used the flamingos to say “Thank you,” in many different languages, for your participation.

Now, the flamingos are saying “Welcome,” in even more languages, to all of our old and new friends coming to this conference. 

As we move forward I’d like to share some crucial dates, thoughts and pictures on how the current form of ICMC came into existence.

The idea for the conference first circulated in the ISO meetings in early 2010. However, atsec started to consider it at the end of 2012, specifically on November the 2^nd, when we first established a repository for the conference with the current name: ICMC.

The name had to address two key aspects: International and Crypto Module, since the focus would be on crypto modules and attract an international audience.

During the first months of 2013 we contacted Bill Rutledge, the current organizer, and started the process. First we had to set a budget and make the funds available.

In April 2013 we set up the Web site, the logo, and started the process of finding the date and venue to host the event. We had to be careful to avoid clashing with the International Common Criteria Conference as the CC and the FIPS communities share the same set of users, vendors and labs.

The venue we picked for the 1^st ICMC was a Holiday Inn. 

It was very frugal, nothing fancy and no entertainment organized after hours. We picked Gaithersburg, to maximize our chances of having as many people from NIST as possible. Google map shows that it’s 1.4 miles away from the NIST campus and it takes 5 minutes to get there. 

The 1st ICMC ran from the 24^th to the 26^th of September, 2013, to avoid collision with the ICCC, which was held on the 10^th to the 12^th of September.  

Once everything was settled for the conference we started to receive reservations. By mid-July, two months before the conference started, we had only four paying applicants registered for the conference! They were a representative of Finnish Communications, two from Coact, Inc, and one from Sicore Technologies. I would like to thank you as early believers in the conference.

The main goal of the conference was to bring the crypto module community together. We knew the risks involved, such as losing money or damaging our company’s reputation if the conference did not go well. We put in a seed, the result of failure or success could be random.

However, shortly after those first 4 reservations, the community came together strongly, and none of the risks we were afraid of materialized. On the contrary, the first ICMC was a success and made a profit. We had a total of 163 participants and 13 sponsors. One Participant Quote was: "This conference is Win Win Win!". 

You can see this quote in our post-conference blog post at:

http://atsec-information-security.blogspot.de/2013/09/a-summary-of-first-icmc-win-win-win.html

A survey after the first ICMC encouraged everybody to continue with the conference:

http://survey.constantcontact.com/survey/a07e896rooghm2en1zl/results

Sixty-four percent of the people surveyed answered that they would definitively plan to attend the next conference and thirty-six said they would maybe attend again, but nobody said that they would not attend again.

After the first ICMC, atsec decided to leave the funds and the profit made with the organizer and the community to continue to prosper the conference.

We consider it one of the best investments our company has ever made, because today after 5 years this conference has more than 20 sponsors and close to 400 participants. 

I want to thank all of our sponsors and exhibitors for supporting the conference. I’d also like to thank the Program Committee for their hard work from planning the conference to putting together the agenda. This year we have some student volunteers. Thank you for your help! My special thanks go to Bill Rutledge and Nikki Principe for making the conference possible.

We have left the infant and toddler phase. Now the ICMC is growing healthier and stronger every year with more sponsors, users, labs and vendors from all market segments and all over the world. The spirit of the conference hasn’t changed: it is a platform where we improve the communication among all parties involved in designing, implementing, using, testing and validating crypto modules while the load of organizing the conference is shared.

Vendors and labs are all competing, but during the ICMC everybody comes together as during the Olympic Games to share with each other the fruit of a hard year of work. However, unlike the Olympics, at ICMC everybody is a winner!

What a great story of community. Thank you very much for believing in it.

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

atsec's International Women - Congratulations

The 8th of March is International Women's Day.

Traditionally, women offer flowers to other women on this day. 

The traditional flower is called a Mimosa, a simple spring-time yellow flower.

Well, it may not be possible to find Mimosa in every country, but we take what is common and yellow and...

Celebrate!!!

ISO/IEC JTC1/SC 27/WG 3 meeting in Abu Dhabi

At the end of October I was once again privileged to be able to  join ISO/IEC JTC 1/SC 27/WG 3 during the latest of their bi-annual working sessions held in April and October.

Convened by Miguel Bañón, this working group is of particular interest to atsec since it includes work on the international standards and guidance documents relating to ISO/IEC 15408, ISO/IEC 19790 and other documents closely related to evaluation and testing and the provision of security assurance.

I have written in more detail on these standards in:

ISO's work related to the Common Criteria
ISO's cryptographic module work.




A little history on the relationship between ISO/IEC 15408 and the Common Criteria reveals that in the early 1990's, as the various national criteria, including Europe's ITSEC, The Canadian Criteria (CTCPEC) and the US Federal criteria, were brought together in order to create a single set of harmonized criteria, the intention was to publish the new set of "Common Criteria" as an ISO standard. A decision was made to create a more agile  technical community, the Common Criteria Development Board (CCDB), that could produce the work and present it to ISO. This was not done using the ISO "PAS" process, but aimed to produce and submit  a substantially complete work that would allow expeditious instantiation of the work with the full involvement of the ISO community, which could then support the standard's future maintenance within ISO.

Hence, the CCDB and ISO established a close liaison relationship, the Common Criteria were submitted to ISO by the CCDB and the first edition of  ISO/IEC 15408 was published in December of 1999.  Since then the CCDB have continued to liaise with ISO enabling the content  of ISO/IEC 15408 and the "Common Criteria" to remain synchronized. It's a two way relationship allowing for changes and innovations from WG 3 to be brought into the CCDB standards development.

The CCDB was initially comprised of representatives from those  countries contributing their own national criteria, today the CCDB is still a subset of  the  17 members of the CCRA certificate issuing signatory nations and the CCDB standards development efforts reflect the needs of the government agencies which they represent.

From the perspective of commercial industry it is a closed group, a little disconcerting when you realize that at least in the U.S., the stated policy is to adopt COTS products as a means of making government systems, more timely and cost-effective  and the US government emphasizes the benefits of public-private partnership.

So, this has been the status quo for several years: The CCDB updates the Common Criteria and the CEM standards using input from the CCDB members and from the WG 3 experts.  ISO publishes the aligned CC/CEM content as the ISO/IEC 15408 and ISO/IEC 18045 standards.

ISO brings to the table a breadth and depth of constituents far beyond that of the CCDB. SC 27 (IT Security Techniques) currently brings together 53 participating nations, a further 20 observing nation and is in liaison with many industry groups and standards organizations such as:
(ISC)2, CCETT, Cloud security alliance, ECBS, ENISA, EPC, ETSI, Ecma International, IEEE, ISACA, ISSEA, ITU, MasterCard, MasterCard
CCDB, TCG, Opengroup, United Kingdom, TMForum, ISA, ABC4Trust, CSCC, INLAC, Cyber Security, TAS3, (ISC)2, PRACTICE, ISF, OECD, FIRST, OIDF, PQCRYPTO, WITDOM, Kantara Initiative, ISCI, PRIPARE, EuroCloud, PICOS, Article 29 Data Protection Working Party, Interpol, ETSI, TREsPASS, EUDCA

The various national bodies and liaison organizations represented in WG 3 work closely within their home fields to garner the participation of, and to  represent the interests of their own constituents.

Over time, the success of the Common Criteria has resulted in interest and use of the CC standards far beyond the national Agencies that are the the constituents of the CCDB. The diagram below attempts to illustrate this:

After a year long joint study period, WG3 and the CCDB recognized this evolution, and noting that ISO has more resources, and more widely represents the diverse stakeholders of the Common Criteria standards,  decided that ISO will take the lead in developing the next revision of the standards.

If you are interested in contributing to the development of ISO/IEC 15408 (The "CC"), ISO/IEC 18045 ("The CEM") or other projects within SC 27 then you can do so either through your national body, or through one of the liaison organizations to SC 27.

By Fiona Pattinson

P.S. in the U.S. the national body is ANSI who are are represented in SC 27 by INCITS.

Second Annual 27K: Security Summit for the Americas meets in San Francisco

From Monday, September 26^th to Thursday, September 29^th, 2016, the second annual 27K: The Security Summit for the Americas took place at the South San Francisco Conference Center in South San Francisco, California. The conference brought together experts in the ISO/IEC 27001 Information Security Management System (ISMS) standard along with people on the front lines of international IT security to promote the standard in the Western Hemisphere. See the 27K Summit website for full details on the conference.

Ryan Hill, Community Engagement Manager for
atsec information security manning their booth

The summit was attended by more than 120 individuals and was sponsored by more than 20 IT security companies, including atsec information security. This year’s conference was focused on the challenges of security in the area of Cloud Computing.

The 27K Summit started with a day of workshops on Monday that covered topics from introductions to the standard to harmonizing ISO/IEC 27001 with other standards. Day two, Tuesday, began with opening remarks from Ryan Hill, atsec’s Community Engagement Manager, followed by keynote presentations from Jim Reavis, Co-Founder and CEO of the Cloud Security Alliance, and Crispen Maung, Vice President of Compliance at Box.

Jim Reavis, CEO of Cloud Security Alliance,
speaking on "Security Assurance at the Speed of Cloud"

The conference continued with presentations on two tracks, Getting Started and Implementation, for the remainder of the day. The Implementation track continued into Wednesday and a new track, Enterprise Issues, was also introduced. In all there were over thirty speakers who presented.

atsec adds Italian Common Criteria Scheme accreditation

atsec is pleased to announce that it has recently been accredited to work as a Common Criteria evaluation laboratory (LVS - Laboratori per la Valutazione della Sicurezza) under the Italian Common Criteria scheme.

OCSI - Organismo di Certificazione della Sicurezza Informatica, founded in 2004, is the Italian scheme which is a signatory to both the CCRA - Common Criteria Recognition Arrangement as well as SOGIS – the Senior Officials Group Information Systems Security.

This means that atsec’s Common Criteria customers have the opportunity to select from the US, Sweden, Italian and German Schemes for their Common Criteria certification.

Helmut Kurth, atsec Chief Scientist stated that the addition of an LVS accreditation by the Italian national scheme to astec’s portfolio allows atsec to support customers in selecting the certification scheme that best fits their commercial needs with respect to certification timeline, cost, and knowledge in specific technical domains.