ICMC16: Introduction on the Commercial Cryptography Scheme in China

Di Li, Senior Consultant, atsec information security corporation

Please note: Di Li works for atsec, and is not speaking for the Chinese Government.

Their focus is on certifying both hardware and software, including HSMs and smart cards.  In China, only certified products can be sold or used. They should be sold commercially. By law, no foreign encryption products can be sold or used in China.

Additionally use their own algorithms. Some are classified, others leverage international algorithms like ECC, others would be considered a competitor to algorithms like SHA2 or AES-GCM.

They have their own security requirements for cryptographic modules, but there are no IGs, DTRs, etc., so it is different. No such concept of "hybrid", either.

There are two roles in the scheme: OSCCA and vendor. OSCCA issues the certificates and they are also the testing lab.  The vendor designs and develops the product, sell, and promote.  They report their sales figures to OSCCA every year.

There are requirements to be a vendor as well! To get sales permission, you need to demonstrate you are knowledgeable in cryptography among other things. 

Validations are updated every 5 years. As a part of this process, you additionally have to pass design review.

You cannot implement cryptography within a common chip , as there is not enough security in that chip.

Banking must use a certified products. The biggest market is USB tokens and smart cards.

ICMC16: Automated Run-time Validation for Cryptographic Modules

Apostol Vassilev, Technical Director, Research Lead–STVM, Computer Security Division, NIST
Barry Fussel, Senior Software Engineer, Cisco Systems

Take a look at Verizon's Breach report. It's been going on for 9 years, and we see things are not getting better. It takes attackers only minutes to subvert your security and they are financially motivated.  Most of the industry doesn't even have mature patching process.

We hope validation can help here, but vendors complain it takes too long, the testing depth is too shallow, and it is too costly and rigid.

In the past, we leveraged code reviews to make sure code was correctly implemented. Data shows that code reviews, though,  only find 50% of the bugs.  Better than 0, but not complete. Can we do better?

Speeding up the process to validate, allows people to validate more products.

Patching is important - but the dilemma for the industry is "do I fix my CVE or maintain my validation?" This is not a choice we want our vendors to make.  We should have some ability for people to patch and still maintain validation.

The conformance program needs to be objective, yet we have different labs, companies and validators relying on these written test reports. This is a very complex essay!  Reading the results becomes dizzying.  We want to improve our consistency and objectivity, how can we do this?  So, we asked the industry for feedback on what the industry looks like and how we could improve the program. We started the CMVP working group.

The problem is not just technical, but also economical. To make changes, you have to address all of the problems.

Additionally, we need to reconcile our (NIST's) needs with NIAP's (for common criteria). 

And a new problem - how to validate in the cloud? :)

The largest membership is in the Software Module sub group - whether that is due to the current FIPS 140-2 handling software so poorly, or reflective of a changing marketplace is unclear.

Fussell took us into a deep dive of the automated run-time validation protocol. 

The tool started out as an internal CIsco project under the oversite of David McGrew, but didn't get a lot of traction. Found a home in the CMVP working group.

One of the primary requirements of this protocol is that it be an open standard.

Case example: Cisco has a crypto library that is used in many different products. First they verify that the library is implemented correctly, but then they need a way to verify that when products integrate it they do it correctly.

The protocol is a light weight standard's based protocol (HTTPS/TLS/JSON). No need to reinvent the wheel.

Authentication will be configurable - multi factor authentication should be an option, but for some deployments you won't need a heavy authentication model.

And Barry had a video! (hope to have linked soon)

If things are going to be as cool as the video promises, you'll be able to get a certificate quickly -from a computer. :)  And if you find a new

ICMC16: FIPS Inside

Carolyn French, Manager, Cryptographic Module Validation Program, Communications Security Establishment

Canada doesn't have the same legal requirements to use FIPS 140-2 validated cryptography, but it's handled by risk management and is strongly desired. They put verbiage in their contracts around this, and also require that the modules are run in FIPS mode.

If you are not using a FIPS 140-2 validated module, we consider it plaintext.  So, if cryptography is required, then you need to use an approved algorithm, in an approved manner with sufficient strength.

Vendors can choose to validate the entire box or just the cryptography itself.  The smaller the boundary, the longer you can go between revalidating.

A vendor may incorporate a validated module from another vendor (eg a software library) into their product. CMVP recommends that you get a letter from them confirming exactly what you're getting. Writing crypto is hard - so reuse makes a lot of sense.

When you are considering leveraging someone else's validated  module, look at what is actually "insdie". For example, what module is generating the keys?

You can rely on procurement lists like the DoD UC APL.

ICMC16: CAVP—Inside the World of Cryptographic Algorithm Validation Testing

Sharon Keller, Computer Scientist, NIST, CAVP.

CAVP used to be within the CMVP, because there were only 3 validate algorithms. They split in 2003, and now CAVP is a per-requisite to doing a CMVP validation with NIST.  NIST's Cryptographic Technology Group determine which algorithms should be included, and how they should be implemented in order to be secure.  CAVP then writes test suites to validate that an implementation meets these requirements.

It's beetter to test something instead of nothing at all. In 2011, introduced component testing when components of an algorithm isn't contained in a single boundary.  It is testing a component of a standard, not a mathematical function.

For example, ECDSA signature generation function has two steps - hash message and sign hash. For the PIV card, hashing of message done off the card and signature of the hash is done on the card.  So, created ECDSA signature generation component that takes a hash-length input and signs it

CAVP now tests SHA3!

Need to make sure everything works correctly, and if it deviates even a little bit, then the test needs to fail.  The Monte Carlo test goes though about 4 million iterations, designed to exercise the entire implementation. Their tests include positive testing - given known inputs, get the right output. Additionally do some negative testing to make sure the implementation recognizes invalid and valid values. For example, change the format of the data before submitting and make sure it fails.
 

ICMC16: Keynote: Modern Crypto Systems and Practical Attacks

Najwa Aaraj, Vice President, Special Projects, DarkMatter

In the past, attacks came from a single user. Today, we have complex and coordinated attacks that target heads of state and world leaders. This can enable terrorism as well.

We need to worry about encryption, key management, and keeping data secure in all manners of transport.On one system, you can't just worry about the communication layer, but also the operating system and how you manage all of this.

First and foremost, we need secure protocols.  We may need non-repudiation, anonymity, etc - need to link it all together.  We need to make sure it's all there.

Of course, if the kernel and hardware have security issues, you'll be in big trouble. Need to worry about data at rest, real time integrity monitor, hardened cryptographic library, key management and hardened OS and kernel.

Encryption should be intractable by theoretical cryptanalysis, but it also needs to be implemented correctly. 

Common side-channel attacks: power analysis, EM analysis and timing.  For example, when you are generating keys power usage will look the same with every key. Most common targets are smart cards, smart phones and FPGA microcontrollers. 

Counter measures are most often implemented at the algorithm level. For example, masking/blinding of randomness, constant time implementations and pre-computations and leak reduction techniques. 

We additionally need protocol level countermeasures to reduce the amount of leakage to less than the minimum required for key recovery using SPA/DPA/EM-based leakage and to reduce interim states that could lead to leakage.

In the hardware level, you can choose NAND gates that don't leak information about power consumption.

You need to consider all of these factors, and additionally make sure you write your software securely as well!

ICMC16: Plenary Keynote Sessions

Welcome and Introduction Ryan Hill, Community Outreach Manager, atsec information security

Changed the time of year for the conference, and location (had to make it International, after all) - and have the largest attendance to date!  Even though it's only 6 months after the last conference.  Seems the new time of year is working out.

Cryptographic Module User Forum (CMUF) Overview, Matt Keller, Vice President, Corsec 

CMUF was founded during the first ICMC, with the goal of getting government and industry to meet and discuss issues.  An open dialogue benefits all.  It's an open group.  Working on improving security policies, to make them more useful for actual users.  A new working group is spinning up to look at power on self tests. Goal is to get a lot of people, each putting in a small bit of time. Join now, and you may win a free registration to next year's ICMC!

Conference Keynote: Building our Collective Cryptographic Community, 
Joe Waddington, Director General, Cyber Protection, Government of Canada

How many cryptographic instances are in this room?  Given there are 270 people here, and each person has a phone (which includes several different cryptographic instances), credit cards, ID cards, car keys.... there are thousands. In one room. And everyone expects these to just work. Nobody gives much thought to whether or not they are effective, we are just trusting that these transactions will be secure.

Think about how many social media accounts in this room - think about the petabytes of information that a company like Facebook is processing every day. We all trust that they will do this in a secure manner.

Now, with IoT, we are putting cameras in our refrigerators.  We don't want other people to be able to look into our refrigerator, so that has to be encrypted as well.

When Waddington joined the Canadian government, he was not surprised to see there were 100 different departments, but was surprised that there were 100 different CIOs, and dozens of HR databases.  This is a big problem and Canada is working on resolving this and consolidating.

Cryptography is hard and takes time to get right - time well spent.  The standards are the 'simple' part here. Complex implementations and software are making this harder to get right. Often with this cloud software development, folks are thinking about supporting their application for ... months. But, we need to protect data for years (30-40 or more!).

Need to partner with government, industry and academia to make sure we are doing the right things. No single organization has the answer.


Conference Keynote: Assuring the Faithfulness of Crypto Modules, David McGrew, Cisco Fellow, Cisco Systems

A faithful module does what is expected and nothing more.  An unfaithful one might have a side channel where it could leak information.

We start out with standards. Those become open source implementations (seems like a prerequisite to get traction for a standard), vendor implementations, etc.  The encryption could become unfaithful at several stages - in the design or implementation phase.  Open Source seems to be a big target, with so many contributors [VAF NOTE: though most seem to have a relatively small core development group].  Companies are at risk as well, need to worry about people being bribed, malicious.

Need to worry about just plain ol' mistakes as well (heartbleed and goto fail;).

You even have to worry about code injection attacks, like changing hard-coded values in a binary.

All sorts of areas to attack: key generation, encryption, etc.

How do we detect this? Black box testing and implementation review.   Can they catch everything? No, but at least a step in the right direction.

Reference: Mass-surveillance without the State: Strongly Undetectable Algorithm-Substitution Attacks. Why bother attacking the cipher itself, if you can undermine the randomness or change the cipher? Much easier. 

We have to worry about protocol side channels as well, like randomized padding, timing channels and variability in options, formatting, and headers.

Still, what can we do? 

Better oversite of our standards, better vetting and formal tracking of reviews for open source [VAF NOTE: quite frankly, industry should do this, too, if they aren't already!].  We need to do security reviews and track them, and additionally independent validation.  Even better - run time validations!

Fortunately, work is being discussed in this area.  See the CMVP working groups that have recently formed.
 

ICMC16: Interested in FIPS? Register now!

I'm giving two talks this year, one on random number generation and the other on backdoors, and how they are relevant to FIPS 140 validations, at the International Cryptographic Module Conference in May 2016.  The conference this year will be up in Ottawa, Canada, which is pretty exciting for me, as I've never been there!

If you work for a validation lab or consulting firm, you're probably already registered - but this conference is particularly important for developers who are trying to pass a validation now or sometime in the future.  I know the conference organizers would love to see more real world users of FIPS 140-2 validated software and hardware as well, so if that's you - come check it out this year!

And the conference goes well beyond simply discussing FIPS 140-2/ISO 19790 - I've seen talks on new algorithms, hardware security,  general cryptography and entropy, and various attacks.

As an added bonus for you, you can register at 20% off using my speaker code: SPDI. Register soon, while early bird rates are still in effect, for added savings.

hope to see you there!

Valerie