Seguridad Moderna para Android Developers (parte 1)
Modern Security in Android a fast guide to be safe
Este post está relacionado con mi última plática “Modern Security for Android Developers”.
Esta es la lista de blogs que tendrá el serial:
- Parte 1 — Encriptación Vol 1
- Parte 2 — Encriptación Vol 2
- Parte 3 — Encriptación Vol 3
- Parte 4 — Biométricos como autenticación local
- Parte 5 — Módulos con Native Code
- Parte 6 — SSL, TLS, Secure Data layer
Primero que nada, hablemos un poco sobre por qué la seguridad en los smartphones es tan importante, en los 90’s la televisión es lo que hoy en día es el teléfono celular, todos tenían uno, incluso si eres clase media-baja la población contaba con una televisión, ahora imaginemos a todas las personas que tiene un teléfono celular con Android, este número se eleva a 2.5 billones de teléfonos activos, es nuestro trabajo como desarrolladores estar conscientes de los peligros de fuera, necesitamos ser extremadamente cuidadosos en favor de dos grandes fuerzas mayores, la primera, la compañía para la que trabajamos, y la segunda, que es mucho más importante, los usuarios que nos dan su data.
Dentro de Google, el equipo de Android, ha trabajado arduamente para tener un sistema operativo realmente seguro.
En el 2018 Android obtuvo 0 critical security vulnerabilities, y repartió parches de seguridad al 84% de los dispositivos, pero aún así tenemos problemas, debido a que no todos los teléfonos logran tener actualizaciones, ya que en muchos países estas actualizaciones dependen de los carriers y aunque los desarrolladores no pueden hacer mucho sobre este gran problema, podemos tratar de proteger a nuestros usuarios de otros males, tomando en cuenta que nuestros usuarios no son adeptos a la tecnología, y fomentando una cultura donde tratamos a nuestros usuarios como una persona del otro lado de la pantalla
La primera vez, que se habla sobre encriptación por lo regular causa una sensación de complejidad y abrumó, se asume que es un tema completamente difícil de tratar, cuando en realidad, es completamente lo opuesto, revisando el siguiente esquema:
El más sencillo esquema de un proceso de encriptación
En este esquema, podemos ver que al inicio de todo, tenemos data que queremos encriptar, esto podría ser la llave de un servidor, información bancaria, o información personal de un usuario. Esta data pasa a través de un algoritmo, y este algoritmo crea una llave para encriptación, cuando usamos esta llave obtendremos nuestra data encriptada.
¿Qué es Cipher, Mac, Signature, y MessageDigest?
Son algoritmos de encriptación, en este post solo hablaremos de Cipher, sin embargo la diferencia entre uno y otro es bastante sencilla y prácticamente trabajan parecido, en mobile usualmente necesitamos una combinación para satisfacer un esquema de encriptación, este esquema está diseñado por un Modo, un algoritmo y un padding, con este esquema podemos crear un Cipher, por ejemplo:
Un algoritmo para esquema puede ser:
Advanced Encryption Standard (AES) o Rivest–Shamir–Adleman (RSA)
Los modos pueden ser:
Simétricos o no simétricos, usualmente deben de ser modo CBG o GCM con llaves de 256 bit
El padding:
Esta parte del esquema no es obligatorio, pero ayuda mucho si la data que planeas encriptar, es más grande que la llave que quieres utilizar, básicamente lo que hace es poner información extra a la data que se va a cifrar.
En Android existe una clase Cipher, que ayuda a crear un esquema, como desarrolladores debemos tomar en cuenta que los algoritmos, padding y modos, están sujetos a las versiones de Android que soporte tu aplicación al igual que el hardware que tiene los dispositivos, para saber más de los algoritmos y el soporte puedes hacer click aquí; por recomendación de seguridad, los desarrolladores no debería de tratar de crear un nuevo algoritmo, esto es completamente innecesario e increíblemente peligroso, así que abstente de crearlo, en la siguiente parte de este serial, hablaremos de cómo puedes usarlo sin necesidad de crear uno.
¿Qué significa que la encriptación dependa del sistema operativo y el hardware?
Prácticamente significa, que dependiendo de tu sistema operativo y hardware podrás realizar ciertas operaciones diferentes a otros sabores de OS, y este tipo de operaciones afectarán el desempeño de tu CPU y memoria por lo que cuando hablamos de encriptación no solo hablamos de software también hablamos de hardware.
Como desarrolladores hay una opción llamada hardware-accelerated que es usada para muchas cosas, se puede colocar en el android-manifest.xml para realizar, por ejemplo, animaciones complicadas o computación de vista, se puede colocar dentro de toda la aplicación o dentro de una activity específica, incluso dentro de una vista, sin embargo, es completamente necesaria para realizar encriptación, en el pasado, precisamente antes de Android 6.0, el proceso de implementación de encriptación estaba basado en dm-crypt device-mapper target, que realizaba las operaciones criptográficas vía las interfaces provenientes del kernel de Linux usando crypto API. Actualmente esto ha cambiado, los nuevos teléfonos tienen espacios dedicados de encriptación que puede acelerarse por si solos, ya que los proveedores de teléfonos han agregado a su kernel un driver para usar crypto API que toma ventaja de SoC’s cryptographic hardware, esto ayuda a que bloques de encriptación sean asignados fuera del CPU principal y asegura tener mayores tiempos de acceso al disco.
Encriptación de Data
El presente es muy diferente a Android 6.0, desde Android 7.0, se soporta la file-based encryption (FBE) la cual permite encriptación de diferentes archivos con diferentes llaves, que pueden ser accesibles y desencriptadas de manera independiente, sin preocuparse de filtrar las llaves dentro de la aplicación.
Google está trabajando en una nueva librería que será entregada en el set de Android Jetpack llamada: androidx.security:security-crypto:1.0.0-alpha02
UPDATE for 23/May/2020: Esta librería ahora cuenta con un Release Candidate
Los archivos y data que deseen encriptar dentro de una aplicación serán protegidas por un sistema con un toque de permisos para prevenir el acceso de otras aplicaciones o atacantes en teléfonos rooteados. Tomando especial cuidado en una mezcla de buen performance y una gran seguridad, implementado hardware-backed en conjunto con Keystore y la presencia del usuario para proveer el key access.
Hablaremos un poco más sobre la librería en la siguiente parte de este serial, sin antes comentar, que esta librería representa una gran limitante, debido a la dependencia de la librería Tink de Google para procesos de encriptación el min SDK soportado es el 23. Sin embargo, Google está trabajando para poder dar soporte a más SDK’s y ha prometido que eventualmente llegará
Esto es todo por este post, si requieres ayuda:
Siempre estoy feliz de ayudar y puedes encontrarme en:
Medium: https://medium.com/@dinorahto
Twitter: https://twitter.com/DDinorahtovar
StackOverflow: https://stackoverflow.com/users/4613259/dinorah-tovar
Happy Coding! 👩🏻💻
