Seguridad Moderna para Android Developers (parte 6)
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
Esta es la parte final de este serial pero también es probablemente la primera parte de un segundo serial “Practical Network for Android Developers” que estará disponible después de la publicación de esta última parte.
En el mundo mobile, es conocido que muchas veces necesitamos algún tipo de servicio para hacer que nuestra aplicación funcione, puede ser una Rest API, tal vez Soap o incluso GraphQL, sin embargo, muchas veces se asume que nuestros servicios estan seguros por que estamos usando una conexión de https, pero en realidad no es completamente real, poniendo algunas herramientas y creando un par de certificados podemos ver nuestras request a nuestros servidores y se vuelven espacios sniffeables usando un simple Charles o un Wireshark.
Transport Layer Security (TLS) es el sucesor del protocolo SSL, TLS es una versión mejorada del primero, funciona en la misma forma que SSL, usando encriptación para proteger la data y la información que está siendo transferida. Estos dos términos usualmente son usados de manera intercambiable en la industria, pero para efectos prácticos hoy nos vamos a referir a ellos como SSL. Para mantener tu aplicación segura necesitamos un certificado SSL, usualmente un servidor necesita una llave privada y una llave pública para que tu app y el servidor puedan hacer handshake, el servidor usa la llave privada dentro de un certificado que ha sido firmado usando public-key cryptography.
Sin embargo, un handshake no prueba absolutamente nada, todos podemos crear un certificado de cualquier página web, por esta razón necesitamos un Certificate Authority!
Certificate Authority
Un Certificate Authority es una organización o una compañía que valida esa identidad como propia, por ejemplo si trabajas en FakeCompnay, puedes crear una identidad de la página, email o incluso una persona, esté certificado digital es basado en una llave criptográfica, y nos da la oportunidad de autenticarnos usando una llave que valide que pertenecemos a esa organización. A su vez esta llave nos ayuda a encriptar la comunicación de nuestra data a través de networks inseguras, esto nos da la posibilidad que nada de nuestra data pueda ser sniffeada en el momento de la transferencia
El certificado creará básicamente dos llaves que son necesitadas, la pública y la privada junto a un CSR que es un archivo que contiene más información de la autoridad que representa, este archivo puede ser de dos tipos, un CER o un PFX
Cuando un certificado es firmado o validado como un Certificate Authority significa que podemos usarlo como un approach al public key ayudándonos a establecer una comunicación segura con third parties a su vez, podemos validar documentos usandolo
CER: Comúnmente usado por SSL para identificar websites y otras entidades
PFX: Contiene data criptográfica de la autoridad, incluyendo private keys y cadenas de certificados
Ambos están criptográficamente protegidos con passwords para mantener las llaves privadas y preservar su integridad. Puedes pedirle a cualquier miembro de tu equipo de DevOps este certificado (si no cuentas con un equipo, la persona que configuró los servidos puede ayudarte)
Podemos agregar este certificado a tu cliente de Http preferido de una manera sencilla:
- Puedes mantener tu certificado en un Raw folder, si y sólo si, el password no es plain text dentro de tu codigo, por que si fuera así, tendriamos exactamente lo mismo que veíamos en Native Module Code
- Una vez que tengamos el certificado, necesitamos crear una instancia de Keystore, recordemos que queremos que esto sea seguro, así que este certificado debería de habitar en un lugar seguro de preferencia ayudado por el trusted execution environment, dependiendo del tipo de certificato podemos crear una instancia default o una PKCS12
PKCS12 define un solo archivo que mantiene multiple data criptográfica como objetos AKA PFX - Necesitamos usar la integración de KeyManagerFactory para utilizar el estándar X509 definido como el formato de llaves públicas que contiene un key y una identidad pública (el hostname, la organización o el individuo) y puede ser un auto firmado o un Certificate Authority
- Una vez que tengamos el KeyManagerFactory y la instancia de Keystore con nuestro certificado, podemos crear una instancia de SSL y TLS
Dependiendo de lo que estemos usando se puede agregar la integración de SSL al HttpClient, en este ejemplo, usaremos OkHttpClient y en las primeras líneas se agregar el SSL socket Factory
Usando esto, estamos asegurando que el handshake de cliente y servidor será seguro e inaccesible por third parties y tu data será transferida de manera segura!
Esto es todo por este serial, muchas gracias. Este serial fue dividido en múltiples pláticas, sin embargo la versión final la pueden encontrar en estas fuentes:
En English con Droidcon EMEA
En Spanish con DevFestLatam
Slides disponibles solo en ingles en mi Speaker Deck
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! 👩🏻💻
