Wednesday, May 15, 2019

International Cryptographic Module Conference 2019 in Vancouver, Canada

After a day of pre-conference workshops, the 7th International Cryptographic Module Conference (ICMC) was kicked off this morning with a welcome address from atsec's VP and Lab Director Yi Mao.

(from left to right: Renaudt Nunez, Stephan Mueller, Fiona Pattinson, Swapneela Unkule, Yi Mao)

 Yi Mao's Opening Speech for the ICMC 2019:

"Good morning everyone!

Welcome to the 2019 International Cryptographic Module Conference! This is the 7th ICMC. It’s a great honor to announce the opening of this exciting conference. This is the first time that the conference is hosted on the west coast, to attract more attendees from the Eastern Hemisphere.
This year we have roughly 350 attendees coming from 24 countries. This conference offers 95 presentations by 115 expert speakers. They are scheduled in six pre-conference workshops and continued through the upcoming three-day conference covering ten content tracks. They range from Certification Programs, General Technology, Post-Quantum Crypto, Embedded Crypto, to Random Bit Generators, Open Source Crypto, Advanced Technology, Attacks to Crypto Modules, End User Experience, and the Crypto Enterprise Showcase.

The ICMC has been a wonderful annual gathering platform for the CMVP, labs, vendors, researchers, and users where we share our passion for cryptography, discuss challenging problems, and work together to find sensible solutions. 

For people who have been attending the ICMC in the past few years, this is a re-union event we look forward to. For our new friends, congratulations on your first exciting step into the cryptographic module validation community. 

Before the ICMC era, like many CST lab managers, I was often under a huge pressure to meet the CMVP’s requirements without having an upset vendor. A validation project often turned into a battle field where the CMVP demands and the vendor fights back. ICMC has been and is instrumental to brings experts and practitioners together to listen and to be heard. The open dialogs help each other to understand multiple parties’ different viewpoints and unify the community.

At the ICMC, we have started lively discussions on several important Implementation Guidance (IGs), as well as initiated the Crypto Module User Forum (CMUF) monthly meetings and many of its working groups. In a few minutes, you will hear key updates on the status of the CMUF. What starts at the ICMC is carried on throughout the year in our daily work until we gather together again to report on our work and congratulate each other’s achievements.

Entropy sources and the related IGs is one of the key discussion topics at the ICMC. IG 7.18 was just published last week to enforce NISP SP 800-90B compliance. It will co-exist with IG 7.15 for the next eighteen months and will then replace it. IG 7.14 remains to be valid.

FIPS 140-3 has long been expected. Back in 2016, we even had a “presidential level debate” on whether or not to adopt ISO/IEC 19790, and the majority of conference attendees voted for the adoption for FIPS 140-3. The very recent announcement of FIPS 140-3 on May 1 in the Federal Registry Notice proves that the voice of this conference is valuable to the decision makers.

As the ICMC continues on in many years to come, I have no doubt that not far from now FIPS modules will be in the cloud, because we are starting to take on this challenge at this conference.
Last but not least, NIST is ready to switch from the CAVS Tool to an Automated Crypto Validation Protocol (ACVP) for algorithm testing. It is a small step for all of us to adopt this change. It is a giant leap for NIST and the CMVP. This year’s conference clip is dedicated to those who contributed to achieving this significant milestone.

We’re in May, and Christmas is still far away, but everyday can be a Cryptomas day!

A group of dedicated hard-working professionals made such a rich conference program possible. Our big thanks go out to the conference committee especially chairs:

Program committee

  • Michael Angelo, Micro Focus
  • Joshua Brickman, Oracle Inc.
  • Erin Connor (Chair)
  • Fabien Deboyser, UL
  • Valerie Fenwick, Intel
  • Shawn Geddis, Apple Inc.
  • Ryan Hill, atsec (Chair)
  • Tim Hudson, Cryptsoft Pty ltd (Chair)
  • Laurie Mack, Gemalto
  • Michele Mosca, University of Waterloo
  • Seth Nielson, Johns Hopkins University
  • Fiona Pattinson, atsec (Chair Emeritus)
  • Nithya Rachamadugu, Cygnacom (Chair)
  • Rich Salz, Akamai
  • Mike Scanlin, NetApp
  • Loren Shade, Allegro Software (Chair)
  • Marcus Streets, Arm (Chair)
  • Lachlan Turner, Lightship Security (Chair)
  • Ashit Vora, Acumen Security
  • Steve Weingart, Highland Tech LLC (Chair)
  • William Whyte, Security Innovation
  • Brian Wood, Samsung Electronics
Conference Production Management
  • Bill Rutledge (Project Director)
  • Jose Ruiz (Program Director)
  • Nikki Principe (Operations Manger)
  • Carrie Chu (Marketing and Operations Coordinator)
This year is special. Fiona is back at the ICMC. Fiona and atsec planted a seed in 2013 and it has been blooming once a year ever since. What an amazing accomplishment!

I’d also like to thank sponsors, exhibitors, speakers and participants. Enjoy the conference and your stay at Vancouver!"

More information about the conference running from May 14th to May 17th at the JW Marriott Parq in Vancouver, Canada can be found here:

Sunday, March 31, 2019

Green Entropy

White Paper
international Think-tank Community (iTC)
April 1st, 2019

Green Entropy
Tasked with consideration of ways and means to reduce the carbon footprint of IT security; after a year of deliberation the iTC have produced the following summary of their report. The full report is available on request to
Research has shown that much effort has recently been expended on reducing the energy needs and increasing the efficiency of data centers [1]. Similarly, much work has been performed and reported in regard to reducing the carbon footprint of I.T. workers and developers [2]. 
Many customers of IT security testing laboratories encourage and even require demonstration of the measures employed by laboratories in support of this endeavor, and often cite ISO/IEC 14001 [3] as an appropriate standard supporting the management of such activities.
Accordingly, the iTC team decided to concentrate their work on other, more fundamental aspects of the problem. Starting with the technology underlying the operation and security of every technology from embedded systems, through to the towering cumulus nimbi of I.T., Big Data and cloud technologies.
Every computer system needs to provision random numbers. Random numbers are extensively used in cryptographic functions as well as in the gaming industry, the quality of the random numbers needs to be sufficient for the purpose; quality factors include having sufficient entropy, timeliness and an element of surprise.
In this paper the iTC provide the following recommendation for green entropy.
Many green entropy sources are available to technologists. These include the number of leaves on a tree (*), the quantity of fish passing a data-center window, the number of steps one walks in a day, temperature jitter, and the sun-rising/-setting time in nanoseconds.
These naturally existing but not easily predictable numbers in our environment can be represented in binary form and the few Least Significant Bits (LSBs) of their binary representations may be used as entropy sources.
The iTC has approached the leading IT security testing laboratory, atsec information security who have confirmed that they are eager to analyze the newly recommended green entropy sources for the compliance of NIST SP 800-90B [4].


(*) For many trees this is applicable for only part of the year.

[1]          Under the sea, Microsoft tests a datacenter that’s quick to deploy, could provide internet connectivity for years. June 5, 2018: Accessed March 24, 2019.
[2]          Green Office, Ways to Reduce Carbon Footprint, Tony Ellison. February 22, 2017: Accessed March 24, 2019.
[3]          ISO/IEC 14001:2015, ISO. Available from all good standard stores.
[4]          SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation, NIST. January, 2018: Accessed March 24, 2019.

Friday, March 8, 2019

International Women's Day

Happy International Women's Day to all our wonderful atsec colleagues in Europe, US and Asia.

Thursday, January 3, 2019

How the U.S. government shutdown affects us.

As many of our customers will be aware, the current U.S. government shutdown can affect their projects with atsec.

This time, the partial shutdown includes the U.S. Department of Commerce, and hence NIST's Computer Security Resource Center. This affects our customers with FIPS 140-2 conformance validations (CMVP), and cryptographic algorithm validations CAVP/ACVP).

The U.S. Common Criteria scheme, operated by NIAP, seems so far to be unaffected.

Of course, the Common Criteria projects with validation by the German, Swedish, and Italian schemes are not directly affected.

atsec continues to work on all of our projects, but notes that where there is a project dependency on NIST’s CMVP or CAVP, then this could affect the project’s progression. This would include any Common Criteria projects with dependencies on new CAVS certificates.

If you have concerns, please contact your atsec project manager.

Monday, November 26, 2018

Automated Cryptographic Validation Protocol (ACVP) support from atsec

atsec is proud to present support for the:

which replaces the legacy NIST CAVS testing. Cryptographic algorithm validation program (CAVP) testing is required for cryptographic modules undergoing conformance testing and validation according to the FIPS 140-2 specification. It is also required for Common Criteria evaluations performed in accordance with the NIAP Common Criteria Evaluation and Validation Scheme.

The Automated Cryptographic Validation Protocol (ACVP) is a network protocol for which NIST provides a server using the protocol which produces test vectors, validates responses and, in the case of successful validation, issues certificates that can be used in support of the Cryptographic Module Validation Program's (CMVP) FIPS 140-2 conformance validations, and Common Criteria evaluations performed under the Common Criteria Evaluation and Validation Scheme (CCEVS) operated by the National Information Assurance Partnership (NIAP).

atsec has developed two tools that provide flexible client-support to access the NIST ACVP server:
  • The ACVP Proxy connects to the NIST ACVP server to request test vectors, store them locally, return locally stored test responses to the ACVP server and obtains the final verdict. The ACVP Proxy is a highly threaded system capable of parallel downloads of thousands of test vectors. At the moment, the threading is artificially limited to 32 threads to control the impact on the ACVP development and testing server.
  • The ACVP Parser picks up the test vectors retrieved from the ACVP Proxy, invokes the cryptographic module under test to generate the test responses for the ACVP Proxy. The ACVP Parser includes all specific test vector handling including the Monte-Carlo Testing which commonly causes concerns with developers.
Both components handle test vectors and test responses as files which are stored in a database allowing the maintenance of tens of thousands of test vectors. Further, the clear separation between the two components allow the complete isolation of the test infrastructure with the cryptographic module from the Internet.

atsec publishes both components as Open Source available at GitHub under a BSD license. The provided code is a clean C99 implementation which allows the compilation on all environments providing a POSIX API. This includes Linux, BSDs, macOS, iOS, Android, Solaris, AIX, Windows with the POSIX interface and other operating systems. This is demonstrated by atsec with an iOS app of the ACVP Parser that executes the iOS CoreCrypto library considering the atsec development environment is Linux.

The ACVP Proxy and ACVP Parser are highly flexible by providing a plug-in framework to support different cryptographic modules. To add a new cryptographic module support to the ACVP Parser, the interface invoking the cryptographic module API must be implemented. The remaining parsing and unparsing code can be left unchanged. Similarly, the ACVP Proxy only requires additional cipher definitions specifying the supported cryptographic
algorithms of the tested module. To obtain the same test vectors for one cryptographic module executing on different platforms, an ACVP Proxy configuration file only needs updating.

The Open Source release of the ACVP Proxy and ACVP Parser currently offers support for OpenSSL and the hash and HMAC support used by the ACVP Proxy. With these plugins, atsec developed full support for the following cryptographic modules that can be fully tested with the ACVP server and are available to atsec customers:

  • OpenSSL
  • Linux Kernel Crypto API
  • GnuTLS
  • libgcrypt
  • libkcapi
  • Nettle
  • NSS
  • Generic PKCS11 tokens
  • OpenSSH
  • Libreswan
  • Strongswan
  • WPA Supplicant part of the hostapd software
  • ACVP Proxy hash and HMAC implementation
  • Apple macOS, iOS, tvOS, and watchOS Core Crypto library
  • Apple macOS, iOS, tvOS, and watchOS Common Crypto library
  • libsodium
  • libnacl
Support for additional cryptographic modules can be developed by atsec with reasonable effort.

During the development of the ACVP Proxy and ACVP Parser, atsec supported the NIST ACVP development team to a large extent. The ACVP server data is tested with all of the  cryptographic implementations mentioned above. During the development process, atsec provided numerous improvement suggestions and bug reports to NIST. atsec is committed to the future development and maintenance of the ACVP Proxy and ACVP Parser.

Monday, September 24, 2018

NDcPP v2.1 has been published!

The Network International Technical Community (iTC) published the Network Device Collaborative Protection Profile (NDcPP) version 2.1 this afternoon (2018-09-24). This is the latest update to the NDcPP series of cPPs. Vendors looking to perform a NIAP evaluation using this cPP will need to wait until NIAP approves the new version. In the past, NIAP has taken about one month to approve the NDcPP once it was published by the Network iTC.

Expect this new cPP to appear on the CC Portal very soon. (

Wednesday, May 9, 2018

International Cryptographic Module Conference 2018 in Ottawa, Canada

After a day of pre-conference workshops, the International Cryptographic Module Conference (ICMC) 2018 was kicked off this morning with a welcome address from atsec's VP and Lab Director Yi Mao. The welcome was followed by keynote speeches from Jason Hart, CTO of Data Protection for Gemalto UK and Scott Jones, Assistant Deputy Minister of Information Technology Security for Communications Security Establishment of Canada.

At the ICMC more than 400 attendees from 26 countries will have an opportunity to exchange ideas, network and learn from over 100 industry experts about commercial cryptography and standards like FIPS 140-2, ISO/IEC 19790, and Common Criteria.

More information about the conference running from May 8th to May 11th at the Shaw Center in Ottawa, Ontario, Canada can be found here:

Thursday, April 5, 2018

Tech Corner: SP 800-56B and RSAES-PKCS1-v1.5 Update

Near the end of 2017, NIAP issued and later retracted Labgram #106. This Labgram warned that RSAES-PKCS1-v1.5 would be disallowed by NIST after 2017 which meant that it would also be disallowed by NIAP after 2017 in CC evaluations. The reason for the retraction was because NIST delayed the publication of their update to NIST SP 800-56B that would effectively disallow RSAES-PKCS1-v1.5-based establishment schemes.

In practice, this disallowance meant that all TLS ciphersuites starting with TLS_RSA_* would be disallowed for use with TLS v1.2 and earlier. This is a large set of commonly supported TLS ciphersuites. Removing them from use would leave only the DH and ECDH-based ciphersuites available for use in TLS.

This update is just to inform you that RSAES-PKCS1-v1.5 is still allowed by NIST and NIAP. We hope to receive updated information from NIST on the SP 800-56B revision at the ICMC conference May 8-11, 2018 in Ontario, Canada.

In the meantime, please be proactive and prepare your products for the eventual disallowance of RSAES-PKCS1-v1.5 and its associated TLS ciphersuites. Also note that the new TLS 1.3 standard has removed support for the static RSA and DH ciphersuites in favor of DHE/ECDHE, pre-shared keys (PSKs), and PSKs with DHE/ECDHE. Thus, static RSA and DH ciphersuites will eventually become a thing of the past in TLS as well as the DSA, MD5, and SHA-224 algorithms.

~Scott Chapman

Saturday, March 31, 2018

atsec partners with major retail outlets for provision of security assurance

In a major announcement, dated April 1st, 2018, atsec information security announces the establishment of partnerships with major retail outlets around the world, in a bid to provide more convenient provision of security assurance to users of commercial IT products.

Users of commercial off the shelf products purchased through major retail outlets can set default profile options such as which technology vendor they prefer, and which program or national scheme is to be used.

atsec services will now include free two-day certificate shipping and a very convenient ordering and re-ordering technology for certificate updates.

For an additional premium, consumers can select products that include OpenSSL and obtain certificate delivery within two hours (available in some areas only).

atsec is also developing an App that will enable compatibility with both Siri and Alexa; and is actively investigating expedited delivery of Security Target , Security Policy and other public facing documents documents by drone. CC validation of the App is expected very soon.