On Firefox “Send”

Mozilla has just released a new service, Firefox Send,  to share files with a higher level of security. Firefox Send is quite easy to use, just access the web-page and upload a file (up to 1GB, one needs to register to upload files up to 2,5GB). The service then returns a link to download the file which the user can choose to be valid up to 1 week and to 100 downloads. For an extra layer of security, the user can also add a Password which is then requested before the download.

Under the hood, the file is encrypted and decrypted in the browser of the user using the Web Crypto API and 128-bit AES-GCM. A short description of how encryption is implemented is provided in this page. The secret encryption key is generated by the browser and appended to the link returned by the server for the download, as in (this is not a valid URL)


where the last part of the URL is the secret key.

This is very nice and simple, but to achieve a higher level of security the user has to find a secure way to share with her parties the download link, and sending it by email is not a good idea.

Obviously the use of a Password which can be communicated in other ways (eg. by telephone) makes it more secure. Still the Password is used to create a signing key (with HMAC SHA-256) and uploaded to the server. Then the server checks that a user requesting the file knows the Password by making her sign a nonce. So the Password is not used to encrypt the file but only for an authentication exchange.

I have not found a full security and threat scenario description for this service (some information can be found here and here), but it would be nice to know which are the use-cases that Mozilla has considered for it. Moreover, from a very quick look at the available documentation, it is not very clear to me which are the information that the server can access during the full life-cycle of an uploaded encrypted file.

In any case, Firefox Send seems to be a new and possibly very interesting competitor in the arena of online file sharing services together with Dropbox, Google Drive etc.

Recent Results on Information and Security

I recently read two articles which made me think that we still do not understand well enough what “information” is. Both articles consider ways of managing information by “side channels” or through “covert channels”. In other words, whatever we do, produces much more information than what we believe.

The first article is “Attack of the week: searchable encryption and the ever-expanding leakage function” by cryptographer Matthew Green in which he explains the results of this scientific article by P. Grubbs et al. The scenario is an encrypted database, that is a database where column data in a table is encrypted so that whoever accesses the DB has no direct access to the data (this is not the case where the database files are encrypted on the filesystem). The encryption algorithm is such that a remote client, who knows the encryption key, can make some simple kind of encrypted searches (queries) on the (encrypted) data, extracting the (encrypted) results. Only on the remote client data can be decrypted. Now an attacker (even a DB admin), under some mild assumptions, with some generic knowledge of the type of data in the DB and able to monitor which encrypted rows are the result of each query (of which she cannot read the parameters), applying some advanced statistical mathematics in learning theory, is anyway able to reconstruct with good precision the contents of the table. A simple example of this is a table containing the two columns employee_name and salary, both of them with encrypted values. In practice this means that this type of encryption leaks much more information than what we believed.

The second article is “ExSpectre: Hiding Malware in Speculative Execution” by J.Wampler et al. and, as the title suggests, is an extension of the Spectre CPU vulnerability. Also the Spectre and Meltdown attacks have to do with information management, but in these cases the information is managed internally in the CPU and it was supposed not to be accessible from outside it. In this particular article the idea is actually to hide information: the authors have devised a way of splitting a malware in two components, a “trigger” and a “payload”, such that both components appear to be benign to standard anti-virus and reverse engineering techniques. So the malware is hidden from view. When both components are executed on the same CPU, the trigger alters the internal state of the branch prediction of the CPU in such a way to make the payload execute malign code as a Spectre speculative execution. This does not alter the correct execution by the CPU of the payload program, but through Spectre, extra speculative instructions are executed and these, for example, can implement a reverse shell to give external access to the system to an attacker. Since the extra instructions are retired by the CPU at the end of the speculative execution, it appears as if they have never been executed and thus they seem to be untraceable. Currently this attack is mostly theoretical, difficult to implement and very slow. Still it is based on managing information in covert channels as both Spectre and Meltdown are CPU vulnerabilities which also exploit cache information side-channel attacks.

NIST Announces Second Round of Post-Quantum-Cryptography Standardization

NIST has announced the conclusion of the first round of the standardization process for post-quantum-cryptography algorithms, that is public key and digital signature algorithms which are not susceptible to attacks by quantum computers.

The announcement can be found here and a report on the 26 participants to the second round can be downloaded from here.

A Practical Look into GDPR for IT – Part 2

I have just published here the second article of my short series on the EU General Data Protection Regulation 2016/679 (GDPR) for IT.

In this article I discuss a few points about the risk-based approach requested by the GDPR which introduces the Data Protection Impact Assessment (DPIA), and a few IT security measures which should often be useful to mitigate risks to the personal data.

A Practical Look into GDPR for IT

I have just published here the first article of a short series in which I consider some aspects of the requirements on IT systems and services due to the EU General Data Protection Regulation 2016/679 (GDPR).

I started to write these articles in an effort, first of all for myself, to understand what actually the GDPR requires from IT, which areas of IT can be impacted by it and how IT can help companies in implementing GDPR compliance. Obviously my main interest is in understanding which IT security measures are most effective in protecting GDPR data and which is the interrelation between IT security and GDPR compliance.

On SHA1, Software Development and Security

It is a few years that it is known that the SHA1 Cryptographic Hash Algorithm is weak, and from 2012 NIST has suggested to substitute it with SHA256 or other secure hash algorithms. Just a few days ago it has been announced the first example of this weakness, the first computed SHA1 “collision”.

Since many years have passed from the discovery of SHA1 weaknesses and some substitutes without known weaknesses are available, one would expect that almost no software is using SHA1 nowadays.

Unfortunately reality is quite the opposite: many applications depend on SHA1 in critical ways, to the point of crashing badly if they encounter a SHA1 collision. The first to fall to this has been the WebKit browser engine source code repository due to the reliance of Apache SVN on SHA1 (see eg. here).  But also Git depends on SHA1 and one of the most famous adopters of Git is the Linux kernel repository (actually Linus Torvalds created Git to manage the Linux kernel source code).

For some applications to substitute SHA1 with another Hash algorithm requires to rewrite extensively large parts of the source code. This requires time, expertise and money (probably not in this order) and does not add any new features to the application! So unless it is really necessary or no way to keep using SHA1 and avoid the “collisions” is found, nobody really considers to do the substitution. (By the way, it seems that there are easy ways of adding controls to avoid the above mentioned “collisions”, so “sticking plasters” are currently applied to applications adopting SHA1).

But if we think about this issue from a “secure software development” point of view, there should not be any problem in substituting SHA1 with another Hash algorithm. Indeed designing software in a modular way and keeping in mind that cryptographic algorithms have a limited time life expectancy, it should be planned from the beginning of the software development cycle how to proceed to substitute one cryptographic algorithm with another of the same class but “safer” (whatever that means in each case).

Obviously this is not yet the case for many applications, which means that we have still to learn quite a bit on how to design and write “secure” software.

On the Security of Modern Cryptography

The security of modern cryptography is based on number-theoretic computations so hard that the problems are practically impossible for attackers to solve. In practice this means that approaches and algorithms to crack the cryptographic algorithms are known but with the current best technologies it would take too many years to complete an attack.

But what if a shortcut is found at least in some particular cases?

This is exactly what some researches [article, arstechnica] have just found for the Diffie-Hellman (DH) algorithm with 1024bit keys, algorithm which is one of the pillars of the security of Web transactions among many other uses. The researchers have shown that for DH with 1024bit keys there exist some parameters (prime modulus) that allow with current technologies to compute the secret encryption keys in short time. In other words, some parameters adopted in DH-1024 can contain invisible trapdoors. The only ways to securely use DH today seem to be:

  • to know how the parameters have been generated and to be sure that they do not allow for any “trapdoor”
  • or to use DH with 2048bit or larger keys.

What does this teach us about the security that cryptography provides to everyday IT?

How should we implement and manage cryptography within IT security?

Is cryptography joining the “zero days => vulnerabilities => patch management” life-cycle which has become one of the landmarks of current IT security?

New Developments in Cryptography

Wired reports in this article of a recent advance in deployed cryptography by Google.

Last summer the NSA published an advisory about the need to develop and implement new crypto algorithms resistent to quantum computers. Indeed if and when quantum computers will arrive, they will be able to crack easily some of the most fundamental crypto algorithms in use, like RSA and Diffie Hellman. The development of quantum computers is slow, still it continues and it is reasonable to expect that sooner or later, some say in 20 years, they will become reality. Also the development of new crypto algorithms is slow, so the quest for crypto algorithms resistant to quantum computers, also called post-quantum crypto, has already been going on for a few years.

Very recently Google has announced the first real test case of one of these new post-quantum algorithms. Google will deploy to some Chrome Browsers an implementation of the Ring-LWE post-quantum algorithm. This algorithm will be used by the chosen test users, to connect to some Google services. Ring-LWE will be used together with the current crypto algorithms adopted by the browser. Composing the current algorithms with Ring-LWE will guarantee a combined level of security, that is the minimum level of security is that of the strongest algorithm used in the combination. It should be noted that Ring-LWE is a much more recent crypto algorithm compared to the standard ones, and its security has not been established yet to a comparable level of confidence.

If the level of security will not decrease and hopefully just increase, it has to be seen how it will work in practice in particular for performances.

For modern cryptography this two-year Google’s project could become a cornerstone for the development and deployment of post-quantum algorithms.

Implementing Cryptography right is hard

The security researcher Gal Beniamini has just published here the results of his investigation on the security of Android’s Full Disk Encrytion and found a way to get around it on smartphones and tablets based on the Qualcomm Snapdragon chipset.

The cryptography is ok but some a priori minor implementation details give the possibility to resourceful attackers (like state / nation agencies or well funded organized crime groups) of extracting the secret keys which should be protected in hardware. The knowledge of these keys would allow to decrypt the data in the file systems, the very issue which has been at the basis of the famous Apple vs. FBI case a few months ago.

Software patches have been released by Google and Qualcomm but, as usual with smartphones and tablets, it is not clear how many afflicted devices have received the update or will ever receive it.

In a few words, the problem lies in the interface between the Qualcomm’s hardware module, called the KeyMaster module, which generates, manages and protects the secret keys and the Android Operating System that needs to indirectly access the keys in this case to encrypt and decrypt the file-system. Some KeyMaster’s functions used by Android can be abused to make them reveal the secret keys.

This is another case which proves how it is difficult to implement cryptography right.

Monitoring Outgoing Traffic to Detect Intrusions

Monitoring outgoing traffic to detect intrusions in IT systems is not a new concept but often it does not seem to be enough appreciated, understood and implemented.

IT security defences cannot guarantee us against every possibile attack, so we must be prepared to the event of an intrusion and to manage the associated incident.

The first step in incident management is to detect an intrusion. Traditional tools like Anti-Virus, Intrusion Detection/Prevention Systems (IDS/IPS) etc. do their job but they can be bypassed. But intrusions can also be detected by monitoring the outgoing traffic.

In my recent personal experience, some intrusions have been detected and stopped because the outgoing traffic was monitored and blocked. Since the deployed malware was not able to call back home, it did not do anything and there was no damage; and since the outgoing traffic was monitored, the intrusion was immediately detected.

But monitoring the outgoing traffic to detect intrusions is becoming more and more difficult. For example attackers are adopting more often stealth techniques like using fake DNS queries. An interesting example has been recently described by FireEye in “MULTIGRAIN – POINT OF SALE ATTACKERS MAKE AN UNHEALTHY ADDITION TO THE PANTRY” . In this case, malware is exfiltrating data by making DNS calls to domains with names like log.<encoded data to exfiltrate>.evildomain.com . Obviously the DNS query fails, but in the logs of the receiving DNS server it is written the name of the requested domain, that is the data that the malware is exfiltrating.

As attackers are getting more creative to hide the back communication between malware and their Command & Control services, IT Security will need to devise more proactive approaches to monitoring and blocking outgoing traffic.