Cryptography is still Difficult to Implement

This is a recurring theme (see eg. this older post), how difficult it is to implement Cryptography in the “right” way. It requires a lot of knowledge and expertise in Cryptography, programming skills are not enough.

Recently I read this article “PRACTICAL BRUTEFORCE OF AES-1024 MILITARY GRADE ENCRYPTION” by Kudelski Security Research, in which they show how it was possible to brute force what was called “AES-1024 military grade encryption“. AES is not broken (and “AES-1024” does not really stand for AES with 1024-bit keys) but the main problem was the custom procedure adopted to transform a user chosen password into an AES encrypting key.

Which again shows how it is difficult to implement Cryptography to attain the expected security goals.

To Password or Not to Password…

It seems that in one year or so we could (or should I write “will”?) finally see the beginning of the demise of passwords. The FIDO Alliance is proposing an extension of their UAF protocol which should make it possible to access many online and company applications without a password. The trick is to use the user’s smartphone as the authenticating device with two significant requirements: the user should confirm her/his identity on the smartphone with a biometric authentication, and the smartphone should be directly connected to the device (PC) which is performing the authentication by eg. Bluetooth. More information can be found on the FIDO website (here) and other articles (eg. here and here).

Still I am worried about the security of smartphones: more and more information, functionalities and security features are based on them, but, for example, we haven’t yet solved the problem of patching the Android system which most smartphone use. And what about using just the smartphone (or tablet) and not a PC to access online / company applications?

Is “Post Quantum Crypto” Going Mainstream – part 2 ?

Openssh has released a few days ago version 9.0 (here the announcement) which features the “hybrid Streamline NTRU Prime + x25519 key exchange method by default.” In other words, the key exchange is performed by the standard X25519 ECDH key exchange algorithm (the previous default) paired with the NTRU Prime, a Post Quantum Crypto algorithm “believed to resist attacks enabled by future quantum computers.” If one of the two algorithms fails to protect the confidentiality of the encryption key, the other should continue to protect it, even if a quantum computer will be able to successfully attack X25519 ECDH alone.

Is “Post Quantum Crypto” Going Mainstream?

We do not know if or when Quantum Computers will arrive: 10 years “at best” for Quantum Computing, “at worst” for Cryptography.

Today Post Quantum Cryptography (PQC) aims to provide algorithms resistant to Quantum Computers but it is still in an development phase (see eg. NIST for details).

Concerning information security and Quantum Computer, today we should worry about at least two issues:

  1. how long it will take to perform the transition to Post Quantum Crypto algorithms;
  2. how to protect information encrypted today with standard algorithms but that should still be protected in 10 or more years.

For the second point, one possibility is to adopt already today the emerging PQC algorithms and “double encrypt” sensitive long-term data with a current algorithm and PQC-devel algorithm, with the hope that if one of the two fails the other will keep protecting the data. And based on this IBM announcement (see also here), this seems to be starting right now.

Defeating MFA with MFA Prompt Bombing

And the the weak link is … the human factor.

Not surprisingly, recent reports (see eg. here) describe how attackers abuse even MFA processes based on Authenticator Apps (on mobile phones). Of course it requires anyway some work, in a generic scenario it requires to know already the username and password of the account or service under attack and protected by MFA. But after that, bombing the user with second factor authentication requests on the mobile App (in the middle of the night) sometimes leads to receive access (by someone who actually would like to sleep).

This should not be possible with FIDO2 token or biometrics based MFA, but the “human factor” is often very little predictable…


Managing Security “in the Clouds”

The number of Cloud security management platform solution categories (according to Gartner) continues to grow. As far as I know, this is the current list:

  1. Cloud Access Security Broker (CASB)
  2. Cloud Workload Protection Platform (CWPP),
  3. Cloud Security Posture Management (CSPM),
  4. Cloud Infrastructure Entitlement Management (CIEM),
  5. Cloud-Native Application Protection Platform (CNAPP)

(For details on what they are, look for example here.) And the list is growing… This means on one side that the market for Cloud security management solutions is growing rapidly, on the other side that Cloud security is really an issue and that we haven’t really yet found a good way to manage it.

Fixing Cryptography is not Always Easy

The latest version of the Zloader banking malware is (also) exploiting a Microsoft Signature Verification bug (CVE-2013-3900) for which the bugfix exists since 2013 (see for example here for more details). In this case the security issue is not due to users not updating their systems with the mandatory security patches but to the fact that the patch is optional and should be installed manually.

The problem is that the stricter signature verification implemented by the Microsoft Authenticode patch which fixes this bug, has an extremely high risk of false positives in many situations, for example some installers can be identified as having an invalid signature. So Microsoft decided to let the user decide if the patch would create more problems than solving some.

The Zloader malware uses this “bug” to be able to run some modified (and then unsigned) libraries. But this requires that the malware is already on the system, so applying this patch does not prevent a system from being infested by this malware.

The issue that, again, this event points out, is how difficult it is to balance strict security, in particular if cryptography is involved, and usability / availability of systems and services.