Android, mobile devices: but how secure is the data in the memory?
Over recent years we have experienced the explosion of the mobile world which, with its exponential growth, has brought new mobile devices into the hands of billions of users, inside which an infinite amount of confidential information is contained. For that reason, it has become fundamental to guarantee the security of the data saved on smartphones and tablets, to protect access in the event of any threats to the security of the device, particularly in case of theft.
For that purpose, it is good practice to guarantee that all confidential information, handled by a mobile application, is made inaccessible to anyone not authorized to access it. Therefore, cryptography must be used whenever the data is to be saved in the phone’s persistent memory. All cryptographic algorithms are based on the generation of a key (or of a pair, in the asymmetric case) and on the fact that only those in possession of the key can decrypt the information. Therefore, it is essential to have tools available to allow the keys to be saved securely and persistently.
In Android, starting from version 4.3 of the platform, the system Keystore has been introduced, a component that allows the applications to save their own private keys, making them inaccessible to any unauthorized process. Despite the component being extremely useful from a security viewpoint (for the reasons described above), there is a crucial problem. In fact, in some situations there is a risk of the key being definitively removed from the system, making all the encrypted data inaccessible.
In particular, this circumstance can arise when the unlocking method (PIN, password or sequence) is disabled or reset, or if a digital fingerprint is added / removed (in the case of biometric unlocking). According to the version of the device, the behaviour can vary; in particular the circumstance described always happens in versions previous to 6.0.
From Marshmallow onwards it is actually possible to prevent this risk by not requesting the “at rest” cryptography of the keys. This means that the keys will be saved without encryption, inside Keystore, increasing the risk that a potential attacker can extract them and then access confidential data.
The risk is much lower in devices equipped with a hardware cryptography component, therefore it is possible to check the presence of this element before proceeding, considering that this would imply the exclusion of a large proportion of devices from the use of the application.
If the restrictions just described are not acceptable for the application that is to be developed, possible alternatives must be considered. There could be, for example, situations in which loss of the information saved is considered an acceptable consequence in order to guarantee its security. This approach is suitable for cases in which the information is read only for the user, assuming that there is a recovery mechanism in the event of loss. In these situations, the ownership of the status belongs to the server, while the in-app database only acts as a temporary cache.
Otherwise, if there is also data produced by the actual user in the database, the approach is not appropriate as the information could become irretrievable if any of the cases described above were to occur.
If none of the solutions proposed up to now is considered acceptable, an alternative method must be provided for generating and saving the key. Many tools have been developed by companies or independent developers in order to offer an alternative to the system Keystore. The solution must be evaluated with great caution as a crucial function for the security of the application is being entrusted to a library developed by third parties.
Alternatively, it could be possible to completely change the approach and avoid saving any keys inside the device, by using, for example, a password only known to the user. This solution would maximize the level of security, but would have a significant impact on the usability, as the user would be asked to enter the password every time they access sensitive data. It should also be considered that a password policy would have to be set that is neither too complex nor too simple. In fact, in the former case would increase the risk of it being forgotten, with the resulting loss of information, but in the latter, words may be used that are very simple to guess.
Risorse e riferimenti consigliati
