Folder permission only for Android application

Asked

Viewed 1,291 times

3

Is there any way to make the files in a folder on sdcard accessible only from the app? (something like chown and chmod) Not necessarily read, but prevent removal and editing through other applications (eg explorer). Disregard devices with root

  • 3

    There’s no way I can do that. You can save your files inside your Android application, as long as they are not too big, and then keep access only by the application.

  • I can do a little research, but I think @Jorgeb’s path is simpler.

  • Felipe, there is a "workaround" to be done that I can’t say works. It would put all files with extension .nomedia, not being listed by MediaServer. Take a look at this question: http://stackoverflow.com/questions/7442895/writing-file-on-sdcard-privately-for-application-android.

  • @Wakim this might even serve to hide the files of MediaServer, but nothing prevents a another app access these files. That is, if it is a simple cosmetic question, it is ok, but if it is a question of safety, the path pointed out by @Jorge B. is more guaranteed. P.S. I don’t know anything about development for Android, but the information of that page wouldn’t be relevant? Type, it describes how each app on the device has its own user id and group id, etc..

  • Yes @mgibsonbr, you’re right yes. I also recommend Fernando’s solution. This information is relevant yes, enhancing security in the permissions of the Internal Storage.

1 answer

3


There is a workable solution if you want to save (possibly large) files to your sdcard and still make them accessible exclusively to your application: generate an encryption key in your application, save it within the application itself (as suggested by Jorge B. in the comments), and use it to encrypt/decrypt the files you want to protect. Thus, you at the same time take advantage of the abundance of space that sdcard offers, without having to overspend the limited space that your application has (a symmetric encryption key, such as AES, takes only 32 bytes).

That question on the Soen shows ways to do this. If you decide to follow it, pay close attention to owlstead user comments - it may be that the answers cited (including accepted) are not safe/reliable implementations. I don’t have enough knowledge to give an opinion, but I warn you... (he seems to know what he’s talking about, unlike me, who is semi-layman on the subject)

That other answer, on the other hand, seems to take good care of every detail (correct key derivation, correct mode of operation, treatment of encoding correct), so that it can be a viable medium. It is not specific to Android, however, but to Java in general - which shouldn’t be a problem at first. I’ll transcribe it here, adapting and commenting:

/** Cria a chave para ser usada na cifragem/decifragem
 *  @param senha A senha mestra. Secreta. Ficará salva junto ao aplicativo, não precisando
 *               ser digitada pelo usuário (deve ser longa). Precisa de um meio de backup.
 *  @param sal 8 bytes aleatórios. Não necessariamente secreto. Ficará salvo junto ao
 *             aplicativo. Precisa constar no backup, junto com a senha.
 *  @returns A chave secreta. Pode-se salvar ela, ou o par senha/sal, seu critério.
 */
SecretKey obterChave(String senha, byte[] sal) {
    SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
    KeySpec spec = new PBEKeySpec(senha, sal, 65536, 256);
    SecretKey tmp = factory.generateSecret(spec);
    return new SecretKeySpec(tmp.getEncoded(), "AES");
}

/* Para cifrar um texto, usando a chave gerada anteriormente. */
byte[][] cifrarTexto(SecretKey chave, String texto) {
    return cifrarDados(chave, texto.getBytes("UTF-8")); // Sempre o mesmo encoding
}

/* Para cifrar um arquivo binário, usando a chave gerada anteriormente. */
byte[][] cifrarDados(SecretKey chave, byte[] dados) {
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
    cipher.init(Cipher.ENCRYPT_MODE, chave);
    AlgorithmParameters params = cipher.getParameters();

    // O IV (Vetor de Inicialização) não é secreto, mas tem de ser diferente pra cada
    // arquivo que for cifrado. Ele é gerado automaticamente pela biblioteca.
    byte[] iv = params.getParameterSpec(IvParameterSpec.class).getIV();
    byte[] cifra = cipher.doFinal(dados);

    return new byte[][] { cifra, iv }; // Ambos são necessários para decifrar! Salve-os.
}

/* Para decifrar um texto, usando a chave gerada anteriormente. */
String decifrarTexto(SecretKey chave, byte[][] cifraIV) {
    return new String(decifrarDados(chave, cifraIV), "UTF-8"); // Sempre o mesmo encoding
}

/* Para decifrar um arquivo binário, usando a chave gerada anteriormente. */
byte[] decifrarDados(SecretKey chave, byte[][] cifraIV) {
    byte[] iv = cifraIV[1];
    byte[] cifra = cifraIV[0];

    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
    cipher.init(Cipher.DECRYPT_MODE, chave, new IvParameterSpec(iv));
    return cipher.doFinal(cifra);
}

Care

It is important to offer the user a means of doing backup encryption key, or password used to derive it (if you use one). Otherwise, if there is any problem with the device and the application and/or its data get lost, the user loses access to all his files.

One way to do this is by using a password/master key - strong - that the user only has to type once when installing the application and/or backing up, and from there it is saved in the restricted area of the application. A simpler password or PIN is used on a day-to-day basis for user authentication.

Motivation

Think of a sdcard as what it is: a storage device external. Being external, it is common and predicted that it will be decoupled from one machine and coupled to the other - so that it cannot depend on any protection offered by the operating system. He needs to protect himself.

(this is an analogous case to you taking a system with Unix/Linux, taking the hard drive and putting it on another computer with a different OS - there is no guarantee that this OS will honor the access permissions. It can let any user access anything...)

The solution default for this case is cryptography. And it comes with all the "pitfalls" and "drip" that you could expect - the main one of them the importance of making backup key. What’s the best way to do this backup, there is no way to say in a general way: it is a balance between the confidentiality and the availability. But whatever you do, the important thing is that you do!

Disclaimer: I have no practical experience with development for Android, but for my understanding of that safety reference everything leads me to believe that this is a viable way. For appliances without root, of course, as asked in the question.

  • Android has a function that encrypts all files, avoiding improper access by another device if sdcard is disconnected from mobile, but this function is not API, it is just a function for Android users to protect their files (has in the settings), I searched for any way to hide a key and found the Keychain http://developer.android.com/reference/android/security/KeyChain.html But honestly... I didn’t understand anything, and I can’t find practically anything about it

  • I think that’s the answer, but I’m going to wait a while to see if anyone’s back but any ideas

  • @Felipe.rce Keychain is responsible for storing encryption keys and certificates asymmetrical. If you want to know more about her, see that my answer to the question "How does HTTPS (SSL) work?". Unless you have very specific needs, you don’t need to (or should) use Keychain directly. In this case, I’m talking about cryptography symmetrical - where the same key is used to encrypt/decipher. I don’t know what you already have ready in this sense, and what you have to do yourself.

  • By the way, I repeat that I have no experience with Android, but by the little I read about "encrypt all the files of sdcard" this even exists, but I did not find any information on how to do backup of that encryption key (I only read that "if you use that same sdcard on another device it will not be recognized"). And, as you pointed out yourself, it is a function of the device as a whole, not of specific applications. For these reasons, it does not seem to me to apply to your case.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.