Risks of Cryptography

Cryptography is too often considered as the “final” solution for IT security. In reality cryptography is often useful, rarely easy to use and brings its own risks, including an “all-in or all-out” scenario.

Indeed suppose that your long-lived master key is exposed, then all possible security provided by cryptography is immediately lost, which it seems to be what happened in this case.

Hardware Vulnerability of Some FIDO U2F Keys

Hardware Security Keys, like Google Titan Key or Yubico YubiKey, implementing the FIDO U2F protocol, provide what is consider possibly the most secure 2nd Factor Authentication (2FA) measure. Indeed the private key is protected in Hardware and should be impossible to copy, so that only the physical possession of the hardware token provides the authentication.

But a recent research (see here for the research paper, and here and here for some comments) shows that a class of chip (the NXP A700X) is vulnerable (CVE-2021-3011) to a physical hardware attack which allows to extract the private key from the chip itself, and then to clone the security key. To fully succeed, the attack requires to know the credential of the service(s) for which the security key works as 2FA and the physical availability of key itself for at least 10 hours. Then the security key is dismounted and the secret key is obtained by measuring the electromagnetic radiations emitted by the key during ECDSA signatures. Finally a new security key can be cloned with the stolen secret key.

From a theoretical point of view, this vulnerability violates the fundamental requirement of an hardware security key, that is that the private key cannot be extracted from the hardware in any way. But it should also be noted that the FIDO U2F protocol has some countermeasures which can be useful to mitigate this vulnerability, like the presence of a counter of the authentications done between a security key and a server so that a server can check if the security key is sending the correct next sequence number which would be different from the one provided by the cloned security key.

On practical terms, it all depends on the risks associated with the use of the security key and the possibility that someone will borrow your security key for at least 10 hours without anybody noticing it.  If this constitutes a real risk, then check if your security key is impacted by this vulnerability and in case it is, change it. Otherwise if this attack scenario is not a major threat, it should be reasonably safe to continue to use even vulnerable security keys for a little while, while keeping up to date with possible new developments or information from the security keys manufacturers. Even in this case, vulnerable security keys should anyway be changed as soon as convenient.

 

Another Example of how Implementing Cryptography is Tricky (and a Score 10 CVE)

It has recently been published the description of Zerologon, CVE-2020-1472 (see here for a summary and here for the technical paper), and do not worry since the bug has already been patched by Microsoft in August (see here). 

The bug allows anyone who can connect in TCP/RPC/Netlogon to an unpatched Active Directory domain controller to become a domain administrator, nothing else needed. The cause of this bug is a minor glitch in the implementation of the cryptographic algorithm AES-CFB8: the Initialisation Vector has been kept fixed at zero instead to be unique and randomly generated (more details are provided in the technical paper mentioned above). 

Always about Security Patching and Updates

These days I keep coming back to the “security patching and updates” issue. So I am going to add another couple of comments.

The first is about Ripple 20 (here the official link but the news is already wide spread) which carries an impressive number of “CVSS v3 base score 10.0” vulnerabilities. The question is again:

how can we secure all of these Million/Billion vulnerable devices since it seems very likely that security patching is not an option for most of them?

The second one is very hypothetical, that is in the “food for thought” class.

Assume, as some says, that in 2030 Quantum Computers will be powerful enough to break RSA and other asymmetrical cryptographic algorithms, and that at the same time (or just before) Post Quantum Cryptography will deliver us new secure algorithms to substitute RSA and friends. At first sight all looks ok: we will have just to do a lot of security patching/updating of servers, clients, applications, CA certificates, credit cards (hardware), telephone SIMs (hardware), security keys (hardware), Hardware Security Modules (HSM) and so on and on… But what about all those micro/embedded/IoT devices in which the current cryptographic algorithms are baked into? And all of those large devices (like aircrafts but also cars) which have been designed with cryptographic algorithms baked into them (no change possible)? We will probably have to choose between living dangerously or buy a new one. Or we could be forced to buy a new one, if the device will not be able to work anymore since its old algorithm will not be accepted by the rest of the world.

PS. Concerning Quantum Computers,  as far as I know nobody claims that a full Quantum Computer will be functioning by 2030, this is only the earliest possible estimate of arrival, but it could take much much longer, or even never!

PS. I deliberately do not want to consider the scenario in which full Quantum Computers are available and Post Quantum Cryptography is not.

On the Latest Bluetooth Impersonation Attack

Details on a new attack on Bluetooth have just been released (see here for its website). From what I understand it is based on two weaknesses of the protocol itself.

A quick description seems to be the following (correct me if I have misunderstood something).

When two Bluetooth devices (Alice and Bob) pair, they establish a common secret key mutually authenticating each other. The secret common key is kept by both Alice and Bob to authenticate each other in all future connections. Up to here all is ok.

Now it is important to notice the following points when Alice and Bob establish a new connection after pairing:

  • the connection can be established using a “Legacy Secure Connection” (LSC, less secure) or a “Secure Connection” (SC, secure), and either Alice or Bob can request to use LSC;
  • one of the devices acts as Master and the other as Slave, a connection can be closed and restarted and either Alice or Bob can request to act as Master;
  • in a “Legacy Secure Connection” the Slave must prove to the Master that it has the common secret key, but it is not requested that the Master proves to the Slave that it also has the common secret key (Authentication weakness);
  • in a “Secure Connection” either Alice or Bob can close the connection and restart it as a “Legacy Secure Connection” (Downgrade weakness).

Now Charlie wants to intercept the Bluetooth connection between Alice and Bob: first he listens to their connection and learns their Bluetooth addresses (which are public). Then Charlie jams the connection between Alice and Bob and connects as a Master to Alice using LSC and Bob’s Bluetooth address, and connects as a Master to Bob using LSC and Alice’s Bluetooth address. Since Charlie is Master both with respect to Alice and to Bob and since he can always downgrade the connection to LSC, he does not have to prove to neither Alice or Bob that he knows their common secret key. In this way Charlie is able to perform a MitM attack on the Bluetooth connection between Alice and Bob (obviously this description is very high level, I sketched just an idea of what is going on).

The bad point about this is that it is a weakness of the protocol, so all existing Bluetooth implementations are subject to it. The good point is that the fix should not be too difficult, except for the fact that many (too many) devices cannot be patched! Fortunately this attack seems not to apply to Bluetooth LE, but still I expect that most Bluetooth devices subject to this attack will never be patched.

But we should also consider the real impact of this attack: to perform it, the attacker Charlie should be physically near enough to the two devices (Alice and Bob) with a dedicate hardware (even if not so expensive), so this limits the possible implementations. Moreover this attack can have important consequences if Bluetooth is used to transfer very sensitive information or for critical applications (for example in the health sector). In other words, I would not worry when using Bluetooth to listen to music from my smartphone but I would worry if Bluetooth is used in some mission critical applications.

Whats’s happening in Cyber/IT Security?

Comparing current reported cyber/IT security threats, attacks and incidents to what happened a few years ago, it seems to me that  something has surely changed (I must warn that these conclusions are not based on statistics but on reading everyday bulletins and news).

On one side, security surely has improved: vulnerabilities are reported and fixed, patches are applied (at least more often), security policies, standards and practices are making a difference. Still managing password and properly configuring systems and services exposed on Internet remain very difficult tasks too often performed without the required depth.

But security has improved, which also means that attackers have been moving to easier and more lucrative approaches which have to do mostly with the “human interface”. In other words: fraud.

The first example is ransomware, that is the attacker is able to access the victim system, copy vast amount of data, then encrypt it or remove it and finally ask a ransom not only to return the data but also to avoid making it public on Internet. Since everybody is getting better in making backups, here the important point is the “making it public on Internet” so that the ransom is asked more to prevent sensitive data to be published than to restore the systems.

The second example is Targeted Phishing attacks, Business Email Compromise and similar scams in which the attacker impersonate a well known or important person by writing emails, letters, making phone calls etc. to convince typically a clerk but in some cases also a manager, to send a large amount of money to the wrong bank account.

Neither of these two types of attacks is new, but now they are filling the news daily. Even if cyber/IT security can still improve tremendously, there have been and there are notable security improvements which makes it that attacks are aimed more often to the weakest link: the human user.

Another Nail in the Coffin of SHA1

A few days ago, a new attack has been made public which makes it easier to forge hash (or “message digests”) computed with SHA1 (see for example this article for more details).

This new collision attack makes it faster and less expensive to create two documents with the same digital signature using SHA1 or, having a digitally signed document where the digital signature uses SHA1 as hash algorithm, to create a different second document which has the same digital signature.

It has been known since a few years that SHA1 is broken and that it should not be used for digital signatures and in general for security purposes (actually NIST suggested to stop using SHA1 already in 2012). But as usual, in the real world there are still many, too many legacy applications which today continue to use SHA1, one example being legacy PGP keys and old PGP digital signatures.

This new result should be at least a useful reminder to all of us to check if we are still using SHA1 in some applications and in case finally update it.

Patching timing is getting tight

The US Cybersecurity and Infrastructure Security Agency (CISA) has recently reviewed the guidelines (actually a Binding Operational Directive for US Federal Agencies) on patching (see the Directive here and a comment here).

Now vulnerabilities rated “critical” (according to CVSS version 2) must be remediated within 15 days (previously it was 30 days) and “high” vulnerabilities within 30 days from the date of initial detection by CISA weekly scanning.

Due to the short time between detection and remediation of vulnerabilities, applying patches in time is going to be difficult, due to the possibily missing availability of patches by the vendors and the time needed anyway to test them in each IT environment.

This implies that there must be in place processes to design, test and deploy temporary countermeasures to minimize to an acceptable level the risks due to these vulnerabilities. And these processes must be fast, they should take at most a few days.