Cryptographic Compliance : Good or Bad ?


Cryptology is not something decision makers have to worry about as long as they comply with the standards. It becomes a bit of a concern, however, when new standards with uncertain, unexpected, or undesirable properties are announced. In this brief note some recent developments on this front are discussed.

Cryptography, the art and science of secret writing, lies at the technical heart of Information Security. The basic cryptographic tools that are ubiquitously present are

  • cryptographic hashes, to quickly ‘fingerprint’ documents ;
  • symmetric encryption, for fast encryption and decryption of large volumes of data ;
  • key agreement, to negotiate the key used for symmetric encryption ;
  • digital signatures,to sign(cryptographichashes of) documents.

The number of choicesfor each of these toolsisbewildering(in sharp contrast to the limited amount of mathematics involved—as described elsewhere in this issue).Thisis not a concernfor corporateinformation security officers,thepersons responsible for theproper choice of technology andproducts. All they have to worry about is that they are following common best practices in compliance with existing or virtualindustrial standards and,if applicable, regulations.Since thosebestpracticesareindeed appropriately named and sincethe standardsresult from years of scrutiny by experts worldwide, there seems nothing wrong with the common ‘compliance’ approach to information security.

Trouble is brewing, however. It is generally felt that the intended level of cryptographic security of several of the standardized cryptographic tools is no longer adequate(simplybecauseprocessorskeepgettingfaster).To make matters worse, it was shown that one of the standardized—and widely used—tools does not even reach that intended level of security.

So, new standards are in the make : according to the webpages of the United States(US) NationalInstitute ofStandardsandTechnology(NIST) [1], Suite B Cryptography will lead the way for the migration to an adequate level of cryptographic securitybytheyear2010.SuiteBCryptography was recently announced by the US National Security Agency [2] (NSA). It is meant ‘to provide industry with a common set of cryptographic algorithms that they can use to createproductsthat meetthe needs ofthe widest range ofUSGovernment(USG) needs.’ Although targeted at US Government use, there can be no doubt that use of SuiteBCryptography will spill overtogeneral use.As aconsequence,the usual compliance approach will soon virtuallyforce companies worldwide to adopt the methods included in Suite B Cryptography.

Suite B is in principle a praiseworthy initiative. It also raises several questions, a first one by its expressed intent. On the Suite B website one reads ‘The sustained and rapid advance of information technology in the 21st century dictates the adoption of a flexible and adaptable cryptographic strategy forprotecting national security information’.Given recent events—namely that well-established and widely adopted cryptographic methods turned out to have unanticipated undesirableproperties—itismandatoryindeed toadopt a ‘flexible and adaptable’ approach to the use of cryptographic methods. Flexibility and adaptability are not reflected in Suite B Cryptography : essentially it proposes just a single cryptographic method for each of the four basic tools mentioned above. Ability to quickly replace a ‘broken’ tool, which is a wise precaution givenpossible andproven cryptanalyticprogress,is not adesign requirement of Suite B Cryptography. The NIST webpage allows somewhat more flexibility in the choice of digital signature and key agreement tools, but does not adequately stress the need for flexibility either.

The lack of flexibility may be compounded by the choice of some of the actual cryptographic tools themselves. Here the situation is as follows. The sole cryptographic hash tool in Suite B Cryptography is SHA-2, which refers to a number of related cryptographic hash functions of different cryptographic security levels. At this point in time there is no reason to suspect that the SHA-2 hashes do not achieve their intended levels of cryptographic security. But there is a concern. Design-wise the SHA-2 hashes are the latest members of a family ofhashes consisting ofMD4,MD5,SHA-0, andSHA-1(listedin chronological order). MD4, and to some extent MD5 and SHA-0, were already known to be weaker than intended. In 2004 and 2005 all these older hashes were shown to have serious design problems. The resulting weaknesses are hard to exploit and can be argued to be irrelevant for many applications. Furthermore SHA-2 does not seem to share these problems with its predecessors. Nevertheless, the mere fact that problems surfaced indicates that the state of the art of cryptographic hashfunctiondesignisseverelylacking.Apparentlythe‘experience’and ‘insight’ that went into the design of functions such as MD5 and SHA-1 was insufficient. SHA-2 contains several supposedly smart tweaks compared toSHA-1 that sofar seem to work since current cryptanalysis of SHA-1 does not affect SHA-2. But for the sole cryptographic hash function included in a new standard, one would liketohavea firmerbasisforone’sconfidence.Unfortunately,awidely accepted alternative to SHA-2 is not available. Would it not be better to postpone the costly Suite B upgrade until a better alternative is available ?
The sole symmetric encryptiontoolincludedinSuiteBCryptographyisthe celebratedAdvancedEncryptionStandard(AES).Thisis without any doubt a well-crafted algorithm, resulting form an international competition and chosen intheyear2000by theNSA after acareful selectionprocess.Sinceitsinvention in the late 1990s, no serious weakness has been found in the AES encryption method despite vigorous attempts by cryptanalysts worldwide. Nevertheless, there is a recent issue that makes one wonder if the same method would have been selected if this issue had been known back in the year 2000.

Theissueisthatsoftwareimplementations ofAES areparticularly vulnerable to so-called cache attacks [3]. The attacker simply observes the cache behavior of her own notdirectly AES-relatedprocessthatis run simultaneously and onthe same processor as the software AES process under attack. It is shown that the datagatheredleaksinformation about the secretAESkeywhich can, as a result, be retrieved in a fraction of a second. Generally speaking, access priviliges are believed to offeradequateprotection and separationbetweendifferentprocesses sharing the sameprocessor.This attack,however,does not require anypriviliges for anything related to the AES process, it suffices to have simultaneous access to the processor on which the AES software is running.

DuringtheAEScompetition, thefact that the cacheis a shared resourcethat leaks information between the processes was either overlooked or considered to be irrelevant. For now any software AES process is at risk, if it runs on a processor that may be shared. This includes servers and any machine without proper access controls such as, most likely, the majority of the machines on the Internet. Protective measureshavebeenproposed to foil cache attacks,but they are not common practice and not part of the standard approach to information security or related best practices.

Given this newinsight, whataboutAES anditsinclusioninSuiteBCryptography ? One would like to see some advisory information in what circumstances AES must notbe used or whattype ofprecautionsmustbetaken.Maybethese precautions are standard practice in some environments, but in most they are not. Restricting usage of AES to ‘hardware implementation only’ is not a realistic option. And neither is it realistic to restrict usage of AES to non-shared environments—quite on the contrary, with the increasedbusiness interestin virtual machines, sharing computational resources seems to be on the rise again, with the obvious consequence for the risk of cache attacks.

For the final two tools, key agreement and digital signatures, Suite B Cryptography announces the use ofEllipticCurveCryptography(ECC) and suggests using a number of standard elliptic curves for this purpose. As long as no pairings areinvolved(and they areindeed notpresentinSuiteB),ECCis amature technology thatby now canbe recommendedforpractical application.However, relying exclusively [4] ontechnologythat may requirelicensing [5] whenimplemented notforUSGovernmentpurposes, will raise some eyebrows.Furthermore, usage of standard curveswith speciallyformattedprimes,iscontradictorytoa ‘flexible and adaptable cryptographic strategy ».

To conclude this brief note, what does cryptographic compliance buy us ? It used to be the safest bet. But it is unclear if blind compliance with Suite B Cryptographyis thebest strategy at thispoint.A widerdiscussion of thepresent situation, in particular on Suite B »s sole reliance on SHA-2 as cryptographic hash, AES as symmetric encryptor, and the ECC licensing requirements, would be welcome.

A final side-remark—or afterthought—of an entirely different nature, is if a higher level of cryptographic security is actually needed. In most practical industrial circumstances the overall securitylevels are not even close to the soon inadequate cryptographic security level provided by the current cryptographic standards. Improving the cryptography does nothing to address that issue. One wonders what the true return on investment could be.

[1] csrc.nist.gov/ispab/2006-03/E Barker-March2006-ISPAB.pdf 

[2] www.nsa.gov/ia/industry/crypto

[3] eprint.iacr.org/2005/271

[4] The NIST website leaves the door open to RSA and traditional discrete logarithm based cryptosystems, with large key sizes.

[5] According to www.nsa.gov/ia/industry/crypto suite b.cfm ‘Any vendor building products for national security use is eligible to receive a license from the NSA. »

Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé


Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.


Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.

Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.