Desde hace tiempo, se viene debatiendo en distintos foros sobre la necesidad de aplicar seguridad al desarrollo software. Tenemos voces en ambas direcciones, tanto partidarios, como detractores. Pero ¿Es realmente necesario desarrollar software de forma segura?
Sí, definitivamente es necesario desarrollar software con criptografía, ya no solo debido a los problemas que podemos ocasionar a la hora de utilizar criptografía débil o vulnerable para proteger nuestros datos (contraseñas HIIP….), sino también a la hora de poder ofrecer servicios seguros ser compliance (ejemplo PCI-DSS, FIPS-140-2/3).
Para ello, podemos basarnos en los estándares como puede ser el estándar de seguridad FIPS 140-2(estandar ISO 19790: 2012 e ISO 24759: 2017), que básicamente es un estándar de seguridad para la acreditación de módulos criptográficos y el cual nos define 4 niveles de seguridad:
- El Nivel 1, que normalmente se utiliza en productos de cifrado de software exclusivamente, impone requisitos de seguridad básicos. Todos los componentes deben estar operativos y no deben existir brechas de seguridad flagrantes de diversos tipos.
- El Nivel 2 requiere autenticación basada en el cargo del usuario. (No se requiere la autenticación individual de los usuarios). También requiere la capacidad para detectar la intrusión física mediante sistemas de bloqueo físico o precintos de seguridad.
- El Nivel 3 añade resistencia a la intrusión física con fines de desmontaje o modificación, de manera que dificulta al máximo los ataques. Si se detecta la intrusión, el dispositivo debe ser capaz de borrar los parámetros de seguridad críticos. El Nivel 3 también incluye protección criptográfica eficaz y administración de claves, autenticación basada en la identidad y separación física o lógica entre las interfaces a través de las que se accede a los parámetros de seguridad crítica y se sale de ellos.
- El Nivel 4 incluye protección avanzada contra intrusiones y está diseñado para productos que operan en entornos desprotegidos físicamente.
Además de tener conocimiento en FIPS-140-2 necesitamos apoyarnos en otros puntos para poder tener una criptografía robusta a la hora de la creación de nuestras aplicaciones como pueden ser:
- Deberíamos utilizar algoritmos aprobados, operación modos, longitudes de clave y tecnologías únicamente debemos escoger entre los diferentes modos de operación vistos hasta la fecha como los de cifrados por bloque ECB, CBF…. Que nos aseguran confidencialidad, pero en ningún caso la integridad… y claramente ser muy cuidadosos a la hora de escoger la longitud de clave que vamos a usar en nuestros cifrados ya que no todas son seguras y algunas son vulnerables a ataques de fuerza bruta
Ejemplo de tabla de algoritmos y sus tamaños:
Algunos de los algoritmos:
- DES: Data Encryption Standard (DES) es un algoritmo de cifrado, es decir, un método para cifrar información hoy en día es un protocolo casi en desuso debido a su tamaño de clave tan corto de 56 bits, muy inseguro.
- 3DES: Triple Data Encryption Standard, como su nombre indica es el algoritmo que hace triple cifrado DES lo que hace es aplicar 3 veces 3 claves distintas de 56 bits, por lo que lo hace mucho más seguro, aunque cada vez más en desuso debido a AES.
- AES: Advanced Encryption Standard (AES), también conocido como Rijndael como veremos en el curso, utiliza un esquema de cifrado de bloques, es uno de los algoritmos es más populares de la criptografía asimétrica y tiene 3 tamaños de bloque fijo:
- 128 bits
- 192 bits
- 256 bits
Hoy en día necesitaríamos ordenadores cuánticos o mucho tiempo (no hay años suficientes de vida) para llegar a romper este tipo de cifrados.
Dejo algunos ejemplos de la fuerza computacional que necesitaríamos para romper AES y el tiempo necesario:
Para romper un cifrado AES necesitaríamos 1 Millon de bilones de años.
Si tenemos aplicaciones web siempre es recomendable generar nuestros certificados con entidades autorizadas como pueden ser:
- symantec
- IdenTrust
- GoDaddy
- Certum
- Trustwawe
Además de tener una generación digital y una verificación correcta:
Y como ha comentado ya algún compañero es indispensable generar nuestros propios algoritmos de cifrado para nuestras herramientas.
- Gestión segura de claves, deberíamos seguir una gestión segura basándonos en 4 pilares:
- Generación de claves usando bibliotecas criptográficas, TPM o HSM Random NumbersGenerators. Como ya hemos visto durante el curso es muy importante utilizar RNG lo mas seguros posibles, como, por ejemplo: los generadores de números pseudoaleatorios criptográficamente seguro (CSPRNG) o el generador de números pseudoaleatorios criptográficos (CPRNG)
- protección de nuestras claves, es importante proteger nuestras claves como ya hablamos si nos cogen todas las claves y todas tienen el mismo cifrado podrían saber que estamos usando la misma clave todos (el default por lo general) por eso es importante cifrar nuestras claves:
- Cifre DEK con KEK., es decir podemos cifrar clave de cifrado de datos con la clave de cifrado de clave, algún ejemplo de esto es Microsoft; que genera una clave de cifrado de claves utilizando la contraseña del usuario. Esta KEK se utiliza para cifrar lo que ellos llaman la clave “maestra” y está realmente es una clave de cifrado de datos. Se utilizará para cifrar cualquier dato que se coloque en el almacenamiento protegido del usuario.
- Guarde las claves: podemos guardar estas mismas en diferentes elementos:
- En un HSM que básicamente es un es un criptoprocesador seguro y resistente a la manipulación basado en hardware que genera, almacena y protege claves criptográficas y normalmente aportar aceleración hardware para operaciones criptográficas) que son una parte indispensable para poder cumplir con FIPS-140-2.
**criptoprocesador: es un procesador criptográfico (microprocesador optimizado para realizar operaciones criptográficas), empaquetado en un dispositivo con múltiples medidas de seguridad física, que le dan ciertas propiedades (por ejemplo, resistencia a modificaciones), que le permiten garantizar que cierta información confidencial se genera, se almacena y se utiliza exclusivamente de forma interna. Esto permite eliminar la necesidad de proteger con medidas de seguridad físicas el resto del sistema.
https://es.wikipedia.org/wiki/Procesador_criptogr%C3%A1fico_seguro
Una aplicación típica de este tipo de dispositivos es la generación, almacenamiento de claves privadas en criptografía de clave pública
- USB cifrado por hardware o software se puede hacer de ambas maneras, aquí algunas diferencias de cada una de ellas:
Cifrado basado en el hardware:
- Utiliza un procesador específico que se encuentra físicamente en la unidad cifrada
- El procesador contiene un generador de números aleatorios para generar un código de cifrado, que la contraseña de usuario desbloqueará Mejor rendimiento por el cifrado de descarga desde el sistema del servidor Claves de seguridad y parámetros de seguridad crítica dentro del hardware cifrado
- La autenticación tiene lugar en el hardware
- Económico en entornos de aplicaciones medios y mayores, fácilmente escalable
- El cifrado está vinculado a un dispositivo específico, así que el cifrado siempre está activado
- No necesita ningún tipo de instalación de controladores o instalación de software en el PC del servidor
- Le protege ante los ataques más frecuentes, como ataques de inicio en frío, códigos malignos y de fuerza bruta
Cifrado basado en el software
- Comparte los recursos informáticos para cifrar los datos con otros programas en el equipo – Solo tan seguro como su equipo
- Utiliza la contraseña del usuario como código de cifrado que cifra los datos
- Puede necesitar actualizaciones de software
- Susceptible a ataques con fuerza bruta, el equipo intenta limitar el número de intentos de descifrado pero los hackers pueden acceder a la memoria del equipo y reiniciar el contador de intentos
- Económico en entornos de pequeñas aplicaciones
- Se puede utilizar en todo tipo de medios
- Separación de las funciones correctamente. Es necesario hacer separación de funciones y optar por una programación modular. Esto, nos ayudará en dos vías, en primer lugar, podremos reutilizar código de forma simple y por otro lado, podremos aislar y analizar cualquier problema o vulnerabilidad en nuestro código, sin necesidad de comprometer la arquitectura al completo.
Por resumir, o se usan nuestra propia criptografía y la almacenamos correctamente o podemos estar expuestos a diferentes tipos de ataques, al igual que si usamos librerías o herramientas de terceros, deberíamos siempre testearlas y no confiar en terceros ya que sus desarrollos pueden estar expuestos a diferentes tipos de vulnerabilidades o fallos en sus aleatoriedades como en los casos que se ha visto expuesto OpenSSL años atrás.
