Dit artikel is ook beschikbaar in het Nederlands.
Cet article est aussi disponible en français.

Cryptography is essential in our society to secure sensitive communications and financial transactions, among other things. Cryptographic recommendations help organisations and teams decide when certain cryptography in their systems should be phased out and replaced. Expressing such cryptographic recommendations as a code has advantages, such as an increased degree of automation and increased insight, and is a logical step towards cryptographic maturity.

Cryptographic recommendations

The recommended algorithms and parameters, including key lengths, for authentication, digital signatures, cryptographic hash functions and symmetric encryption, among other things, change regularly. Algorithms that were once recommended are now insecure. The same applies to cipher suites in communication protocols such as TLS. Cipher suites are combinations of cryptographic algorithms and parameters agreed upon by the communicating parties. On this basis, a secure channel is then set up.

In many countries, including our neighbours Germany, France and the Netherlands, the national information security agencies publish detailed recommendations on the use of cryptography. Usually a distinction is made between cryptography that is recommended, cryptography that is not recommended but is still considered secure, cryptography that we should phase out and, finally, cryptography that is insecure. Those recommendations are regularly updated. The German BSI does this on an annual basis, for example.

We still lack such recommendations in Belgium. These should ideally be formulated at European level, by ENISA, the European Union Agency for Cybersecurity, for example. Unfortunately, we are not there yet. At the same time, Smals and the Belgian public sector certainly have a concrete need for them today, which is why Smals Research took the initiative a few years ago to formulate its own internal recommendations. These are based on the recommendations of the German BSI, as it is the leading and best subsidised cyber security agency in Europe.  

Recommendations as code

As with all other cryptographic recommendations, these are currently expressed in a way that is legible to humans, but not sufficiently structured to allow processing by machines. The latter would allow a higher degree of automation and could improve security.

• It could allow to automatically generate the cryptographic part of the configuration files for communication protocols such as TLS and OpenSSH. As a result, updates could be implemented faster, with less manpower and less risk of human error. Smals uses hundreds, if not thousands, of machines that must be able to communicate securely.
• This would allow us to unlock the cryptographic recommendations interactively. A project team would be able to quickly consult the most recent cryptographic recommendations relevant to them via a web interface. Once the application is live, a project team would automatically be kept up to date on changes relevant to them.

The closest thing available today is the website CipherSuite. While this is a commendable initiative, we would prefer to proceed with Smals for several reasons. After all, we do not necessarily follow these recommendations, which are also limited to the TLS communication protocol. We also want something that is CBOM compatible.

Cryptography Bill of Materials (CBOM)

In the context of the threat posed by powerful quantum computers, another major crypto migration is becoming increasingly urgent. In order to prepare for this and other future migrations, organisations would be wise to start building an overview of which cryptography is being used where. This would allow them to draw up a well-founded migration plan and will also make the migration itself run more quickly and smoothly. This inventory quickly becomes very complex and is therefore ideally expressed as code to facilitate automatic updating and processing by machines.

To this end, IBM developed CBOM (Cryptography Bill of Materials), which allows cryptographic components such as algorithms, parameters, protocols and libraries and their dependencies to be expressed in JSON. It is an OWASP CycloneDX standard, which means that it is compatible with SBOM (Software Bill Of Materials), among other things. CBOM allows us to take the management of cryptographic assets (algorithms, protocols, libraries, keys, certificates, …) to the next level.
The illustration below is a CBOM fragment that shows where RSA-2048 is used in the scanned source code of an application.

Suppose an organisation expresses its cryptographic assets as CBOM, and has cryptographic recommendations in code compatible with it. That organisation could then very quickly determine where and to what extent it complies with the cryptographic recommendations, or not. This insight could be particularly useful when taking steps to make the organisation and the data it protects more secure. An organisation could then quickly find out where it is most vulnerable to powerful quantum computers. The organisation can also quickly provide exact information during audits, for example in the form of an automatically generated report in PDF or Excel format, in response to specific questions from the auditor.

Deviations as code

Aside from the recommendations and the cryptographic assets, there is a third element that can be expressed as machine-readable code: the deviations from those recommendations.

In an ideal world, Smals would systematically and solely use the recommended and secure cryptography in its systems. This is not always possible, given that it would de facto make services unavailable to the users of those systems. We cannot expect doctors, pharmacists, physiotherapists, Public Welfare Centres, etc. to support only the latest secure cryptography at any given time. Smals must therefore show a certain degree of tolerance whereby it continues to support sub-optimal cryptography for a limited period of time. This should be done in a structured manner, with a limited tolerance period and with the risks clearly assessed by security services and approved by management.

This too is best expressed in a way that allows automatic processing. Combined with the recommendations and inventory, this allows us to see immediately where we deviate from the recommendations, both documented and undocumented. This approach also provides insight into the cumulative risk, which helps increase safety in the organisation. This, too, can be useful in audits.

Conclusion

A few years back, Smals Research made a proposition for cryptographic recommendations, which was adopted by Smals and is updated at least annually. Smals Research believes the time is ripe for the next step and is currently converting these recommendations into a structured form with a maximal compatibility with CBOM. The same is done for deviations from those recommendations.

CBOM and Smals’ ambitions to express cryptographic assets, recommendations, as well as deviations in a machine readable format fit into the broader trend of Everything as code, a philosophy that results in an increased degree of automation of processes and management. This gives us more insight and allows us to better anticipate and intervene if necessary. Moreover, it results in increased consistency and scalability thanks to reduced human intervention.

Applying Everything as Code to cryptography is, in our opinion, an important step in increasing cryptographic maturity. We therefore see CBOM as a necessary standard that we expect to see increasingly supported in tools for development, information security and post-quantum migration in the coming years. Consequently, we expect vendors to increasingly provide a CBOM with their software, hardware or services.

We expect the triumvirate of cryptographic assets as code, recommendations as code and deviations as code to unlock new possibilities and opportunities for insight and automation. One idea is to perform graph analytics (graph analytics) on this data, ideally using a graph database supplemented with an interactive visualisation tool.

To be continued. Please do not hesitate to contact us if you are interested.

---

This contribution was submitted by Kristof Verslype, cryptographer at Smals Research. It was written in his own name and does not represent Smals’ position.