ICMC: Explaining the ISO 1970 Standard, Part 2

Randall Easter, NIST, Security Testing, Validation and Management Group

ISO 19790 is available for purchase from ISO (in Swiss Francs) or ANSI (US Dollars), and you'll also need the derived test requirements (ISO/IEC 24759) .

In this section, Randy walked us through a deep dive of the sections of the document.

There is a new Terms and Definitions section, which will hopefully help to clear up ambiguity and help answer a lot of the questions they've gotten over the years.

The new document has all of the SHALL statements highlighted in red, with [xx.yy] - where xx indicates the clause and yy is anumeric index within the clause. This will make it, hopefully, easier for two people to have a conversation about the standard.  The plan is, when errors are found and fixed with addenda, there will be complete new revisions of the document available - ie everything in one place.

Errors were found during translations to Korean and Japanese, when the translators just could not figure out what something was supposed to me (turns out, it wasn't clear in English, either). We should expect more changes as people start to implement against this standard.  Errors will be corrected again in revisions. Mr. Easter was not clear what ANSI/ISO charge for revisions of documents.

There will be four levels for validation again. The requirements vary greatly for physical security between the levels, from "production grade components" to "tamper detection and response envelop, EFP and fault injections mitigation".  You will still need environmental controls for protecting key access, etc.

There are algorithms like Camelia that the US Federal Government are not allowed to use, but vendors are designing software for international markets.  So, federal users can only use certain algorithms - the vendors do NOT have to restrict this, it is up to the end user to implement and use the policy correctly.  How do you audit that, though?

ISO standard states that every service has to have a "bit" that tells whether or not it's an approved service or not.  This should enable this to be better audited.

This is a great policy, but what happens when you have to work what you get? For example, someone could send the IRS a tax return encrypted with RC4. The IRS can decrypt using RC4, but would have to store using AES.  It would be good to know what has happened here.

The new ISO standard has requirements around roles, services and authentication. The minimum role is the crypto officer - there has to be logical separation of required and optional roles and services. The higher up the the levels go, the more restrictions: like role-based or identity based authentication all the way up to multi-factor authentication.

There's been a lot of questions about FIPS 140-2 about what we mean by "list all the services". Does that mean only all the approved services? No, all services - even non approved security functions. Non security relevant services also have to be listed, but that can refer to a separate document. [VAF: curious still, what exactly that means - an OS provides a LOT of services!]

ISO 19790 has new directives of managing sensitive security parameters - for example, you have to provide a method to zeroize keys.  This could be done procedurally by an operator, or as a result of tamper. Other examples this area covers: random bit generation, SSP generation, entry, output and storage of keys.

Self-tests have changed. Pre-operational tests cover software/firmware integrity, bypass and critical functions tests.  Crypto operations can begin to proceed while these tests are running, but the output cannot be provided until the pre-operational tests have completed.

Known answer tests are now all conditional tests, like pair-wise consistency checks.  Vendors can continue to do all of the tests up front, or as needed. Lots of flexibility here.  Mr. Easter made a note I couldn't quite follow about module updates being signed by the crypto officer - not clear why it wouldn't be the vendor. [VAF: I may have missed something here.]

The new standard still allows simulation environments for testing, and special interfaces for the labs to test against that may not be needed by the consumer.

Surprising to NIST, some consumers don't care about FIPS 140 validations and the vendors want to provide that to them.  For example, some of the tamper evident seals may need to be installed by the cryptographic operator, or some initialization procedures. Some customers may not even care about power-on-self-tests EVER being run, so that configuration information has to be part of the integrity check.

As a note: some of the current FIPS 140-2 implementation guidance will be retained with this new standard, as they are newer than the ISO standard, or too vendor specific to be included in a general document.

The vendor may have mitigation against some attacks that there are no currently testable requirements available, and that would be allowable through Level 3. Once you get to Level 4, you have to prove your mitigations.

The new standard allows for degraded modes of operation - for example, if one algorithm stopped functioning properly the rest of the algorithms could still be used.

Something new: here has to be a way to validate that you're running a validated version and what the version number is.  This is interesting and tricky, because of course you get your validation done on released software, so when you ship you don't know that you're validated.  And if you store validation status in another file, it could easily get out of date (ie updates done to the system, but software still reporting it's validated). There are ways to solve this, but vendors should tread carefully.

Also, Annex C (and only Annex C) which covers approved security functions (ie algorithms) can be replaced by other countries, as needed.

Q&A:

Q: "How does software have an 'opaque' coating?" A: "Physical security requirements do not have to be met by software modules".

Q: "Lots of services could be going on, what do we need to be concerned with" A: "Services that are exposed by the module, via command line or API. Security services need be be queryable".

Q: "Why should the crypto officer be signing new modules? They may not be able to modify the trust anchors". A: Was using crypto officer as an example, policies could vary - but it is the crypto officer's decision on what to load.