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.


News on Fully Homomorphic Encryption

Fully homomorphic encryption (FHE) would drastically improve the security of sensitive computations and in general of using Cloud and third party resources, by allowing to perform computations directly on encrypted data without the need to know the decryption key. 

But as of today, fully homomorphic encryption is extremely inefficient making it impractical for general use. Still development is continuing and new results are achieved. For example recently IBM announced an Homomorphic Encryption Service, which is probably more like an online demo but the purpose seems to be to simplify the path for an early adoption by specially interested parties. But IBM is not alone and, among others, Google and Microsoft are developing Open Source libraries which can be used by a developer expert in cryptography to build for example end-to-end encrypted computation services where the users never need to share their keys with the service.

ATP Attacks and Single Point of Failure

We are all following the development of the “SolarWinds incident” but one comment comes to my mind (see also this Advisory from NSA).

There is a very difficult trade-off between management of IT in general but also of IT security, and security itself. To manage IT, from network to servers to services, and IT security it is definitively more effective to be able to do it from a central point, adopting a single strategy to manage and control everything in the same way and at the same time (the “holistic” approach). This means to have a single/central console/point to manage and control all of our IT systems and services, a single point in which to authenticate all users (eg. Federated Single Sign-On) etc. This approach is becoming more and more a requirement as we are moving  towards a service-based IT where services can be anywhere in Internet, access requires a Zero Trust approach, and security is applied at a very granular level to all systems and services.

Doing this we can vastly improve the security of each single system or service, and gives the possibility to monitor each single access or transaction. But in doing so we concentrate in single points activities crucial in particular for security: What can happen to systems and services if the central management console is taken over? What can happen to systems and services if the central authentication service is infiltrated?   

Malware, Ransomware & co.

These days, apart from reading about major incidents like the SolarWinds one, I keep hearing directly from people I know about malware incidents, ransomware incidents and so on. My personal statistics have never been so high. I do not know if this is a personal unlucky end of an unlucky year or a very bad end of an already bad year. I wish to everybody a pandemic-free (in all senses) 2021!  

Mixed Results on AI/ML from Google

Artificial Intelligence, or better Machine Learning, is increasingly becoming part of everyday IT, but it is still unclear (at least to me) which are its real potentials, limits, risks etc.

For example, very recently there have been 2 somehow contradictory news from Google/Alphabet funded research in AI/ML:

  • the paper “Underspecification Presents Challenges for Credibility in Modern Machine Learning” (here the full paper) studies some possible reasons why “ML models often exhibit unexpectedly poor behaviour when they are deployed in real-world domains“, but it is unclear (at least to me) how much these Challenges can be overcome;
  • CASP has announced (here the announcement) that DeepMind AlphaFold has practically solved the problem of predicting how proteins fold, which is fundamental to find cures to almost all diseases, including cancer, dementia and even infectious diseases such as COVID-19.

Thoughts on Blue/Red/Purple Teams and defending from Targeted Attacks

Defending against Targeted Attacks (and even more against Advanced Persistent Threats, APT) is difficult and usually quite expensive. 

We all know the basis of IT security, from cybersecurity awareness and training to anti-malware, firewall and network segmentation, hardening and patching, monitoring and vulnerability assessments / penetration tests (VA/PT),  third-party cybersecurity contract clauses, etc.

But this is not enough. We need also Single-Sign-On (SSO, or even Federated Authentication) and Multi-Factor-Authentication (MFA), Zero Trust architectures, tracing of all local, remote and mobile activities (networks and hosts), SIEM data collection/management and SOC analysis, a cybersecurity Incident Team and an Incident Response plan.

But to defend against Targeted Attacks we need to go another step further. We have designed and implemented all security measures we could think of, but are they enough? Did we forget something? For sure we are ready against an everyday malware attack, but a Targeted Attack which could take months to study us and be implemented?

To answer this question it seems that the only possibility is to think and act as the attacker and look at our IT environment from this point of view. It is here that Blue, Red and Purple teams enter into play as they play the roles of attackers and defenders on our IT environment to test our cybersecurity standing to its limits. They will find holes and access paths we did not think about or even believe possible, but also smarter ways to defend ourselves.

But … what about a Risk Based approach to Security?

In other words, how much is it going to cost us?

Can we afford it?

Finally, is it worth going “all out” or, by accepting some risks, we can continue to do what we have been doing all along in cyber/IT-security? And in this case, how do we evaluate these “Risks” we need to accept?

PS. The last is partly a rhetorical question on my side.

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). 

Zero Trust and Dynamical Perimeters based on Identity

NIST has recently published the final version of SP 800 207 “Zero Trust Architecture” which is a recommended reading.

This gives me the opportunity to consider how vastly the IT architecture has changed in the last 20 years. From the concept of a single IT physical perimeter, we now have multiple physical or virtual perimeters which can be dynamic due for example to Software Defined Networks or Cloud services.

But most importantly who and what is inside a perimeter, which can be even a single application, depends not only on the physical and/or virtual location of the device (both server and/or client) but on the identification / authentication / authorisation of the user and/or the device. So, given the proper identification / authentication / authorisation, a user and its device can be admitted inside a high security perimeter even when connecting from any network in the world. 

Moreover, authentication and authorisation are not “once for ever” but each, even tiny, perimeter should perform them again. This requires strong authentication processes which both authenticate the user and also her/his device and its security. Often this process can be done in two steps: the user authenticates her/him-self to the local (portable) device typically with MFA / Biometrics etc., and the device then manages the authentication to the remote services thus providing a simpler user experience.

This is the development we see every day in most major IT / Cloud services, and which, sooner or later, will also lead to decrease our dependency on the use of Passwords. 

Subject Matter Experts On Artificial Intelligence and IT Crime

Artificial Intelligence (AI), in all its different fields from Machine Learning to Generative Adversarial Networks, has been subject to a study (here the link to the paper), or probably better an evaluation, by a group of Subject Matter Experts (SMEs) to identify the most risky scenarios in which attackers could use it, abuse it or defeat it. The scenarios include cases in which AI is used for security purposes and an attacker is able to defeat it, or AI is used for other purposes and an attacker is able to abuse it to commit a crime, or an attacker uses AI to build a tool to commit a crime.

Overall the SMEs have identified 20 high level scenarios and ranked them by multiple criteria including the harm / profit of the crime, and how difficult it could be to stop or defeat this type of crime.

It is very interesting to see which are the six scenarios considered having highest risk:

  • Audio/video impersonation
  • Driverless vehicles as weapons
  • Tailored phishing
  • Disrupting AI-controlled systems
  • Large-scale blackmail
  • AI-authored fake news.

More details can be found in the above mentioned paper.