Mensajes

Osea que si no tengo el IV el archivo quedaria inutilizado porque no podria descrifralo completo al faltarme el ultimo bloque, ¿no es asi?.

Así es, pero es el primer bloque no el último. Acabarías descifrarando el documento casi en su totalidad, pero perderías información. Lo mismo sucede si se utiliza un IV distinto al original. Si te interesa aprender lo básico sobre cifrado por bloque -> https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

Cualquier duda adicional que te surja posteala por aquí y veremos en que podemos ayudarte.

Saludos!

Buenas XKC vamos por partes,

cuando envio los archivos los cifro con AES 256 y luego envio un nombre de usuario junto con la clave simetrica anterior al servidor, todo ello cifrado con una clave publica y que el programa cliente se descarga y lee (formato .pem).

Cifras el archivo con AES-256, la key AES la cifras con la pública del servidor y el nombre del usuario con la AES. Pero no veo que se haga ninguna firma digital sobre el mismo, por lo tanto cualquiera que esté escuchando puede alterar la conexión ya que tu mecanismo no provee de autenticación. Un atacante sería capaz de sustituir ese archivo cifrado por otro distinto con otra AES distinta y aun así el servidor lo almacenaría.

De alguna forma cada usuario tiene que tener un par de claves privada/pública siendo la pública almacenada en el server para que valide las firmas digitales. El atacante para impersonar al usuario ahora tendría que tener la privada del usuario.

Me da problemas el cifrar con RSA en el cliente utilizando CryptoServiceProvider y a dscifrando con openssl en el servidor. ¿Esto debe dar problemas¿, ¿se puede hacer asi?

Puede dar problemas, sí. Tendrás que asegurarte leyendo la documentación de ambas APIs de que utilizan el mismo estándar y parametrización para que ambas sean comunes.

2.Otra duda es el vector de inicializacion del AES, es necesario que lo envie al servidor(osea, ¿es necesario para descifrar o solo para cifrar?), y supongo que si es asi ¿deberia ir cifrado con RSA?.

El IV (initialization vector) se utiliza para que dos plaintexts bajo la misma clave den dos ciphertexts distintos. Por eso es importante usar IVs distintos si se reutiliza la misma clave simétrica varias veces. El IV se suele enviar concatenado al ciphertext en su inicio es decir IV || Ciphertext y debe viajar en plano ya que es un valor trivial, no deberías cifrarlo aunque si así lo deseas eres libre de hacerlo. Sin el IV te quedará un bloque sin poder descifrar lo que se traduce en 128 bits perdidos.

Saludos!

@El_Andaluz: El tema es que WPA y sucesores al formar el 4-way handshake utilizan un hash sobre una password derivada de la passphrase PSK (contraseña del wifi basicamente). Por lo que ví tu querías hacer una variante que adivinará dígitos en vez de generar palabras, y sinceramente, aunque sea erróneo, no está de más ser retorcidos y pensar en soluciones alternativas, te lo digo porque muchas veces ese pensamiento me ha traído grandes beneficios.

Ahora te explico el por qué, en dicho handshake se calcula un hash sobre la PMK (la pass derivada de la PSK) y la única forma es calcular hashes de palabras hasta encontrar el de la password, como en cualquier esquema de seguridad por autenticación. Nunca se envía la pass en plano, sino un dato que provea al otro extremo de que estás en conocimiento de la misma.

@engel lex: Mencionas AES, pero eso ya es harina de otro costal AES se utiliza (como bien sabes) para el cifrado de la información mediante crypto simétrica. Dicha clave se computará después del tema que estamos tratando. Hombre, si rompieras AES en tal caso simplemente podrías descifrar cualquier paquete de red, pero es más facil "romper" o "adivinar" la PSK para poder reversar el handshake del protocolo WPA.

Saludos!

Código [Seleccionar] Expandir

kwws://dgv.xv.h-sodqqlqj.qhw/he/6/7fg0/e23g15f7dg0f27ii

Analizándolo 1minuto véase que kwws debe ser http por lo tanto calculamos el desplazamiento de h a k, de w a t y de s a p. Ambos son constantes en 3, por lo tanto es un cifrado caesar.

La url descifrada es esta -> http://ads.us.e-planning.net/eb/6/7cd0/b23d15c7ad0c27ff

Saludos!

Buenas, siento la tardanza.

No hay mucha diferencia entre cifrar con .DER o .PEM:

openssl rsautl -encrypt -keyform der -inkey id_rsa.pub.der -pubin -in key.bin -out key.bin.enc

Es el comando que puse arriba modificado para cifrar la clave simétrica AES con la pública de dentro del certificado en formato DER.

Con smime:

openssl smime -encrypt -aes256 -inform DER -in fichero_a_cifrar.extension -binary -outform DER -out fichero_cifrado.extension cert.pem

Lo que hará será generar una AES-256 aleatoria, cifrar el fichero con la AES y cifrar la AES con la pública del certificado. Para descifrar basta con:

openssl smime -decrypt -in fichero_cifrado.extension -inform DER -inkey tu_privada.pem -out fichero_en_plano.extension

He testeado OpenSSL sMIME generando claves en .DER desde cero y puedo decir que funciona 100%.

Saludos!

Hace un tiempo encontré varias vulnerabilidades en empresas conocidas, la gran mayoría no ofrecían un programa de recompensa aun así escucharon mis propuestas y acabaron solventando los fallos.
Sobre las que si tienen el programa, aceptaron mis propuestas sin embargo, aun preguntándoles los criterios de participación en el mismo, consideraron que las vulnerabilidades no cumplían todos los requisitos, así que he votado por la opción 2.

Saludos!

Bueno, y lo mejor de todo es que con esa clave simétrica se tienen que cifrar posteriormente otros dos campos con el algoritmo AES, Modelo ECB y PKCS5Padding. Casi nada  

¿Modo ECB? En serio Si este proyecto es para un entorno profesional (no académico) entonces olvídate de ECB por completo. Te explico el problema:

Imagina que tienes un mensaje de 512bits en un entorno ideal, así que divides el mensaje en 8 bloques de 64 bits. Imagina que el primer bloque y el segundo tienen secuencias parecidas, como ECB no concatena los bloques como otros modos de cifrado como CBC entonces comparando los dos primeros bloques ganas información, y el atacante sabría que información se repite, aunque no sepa que hay detrás de la información. Otra vulnerabilidad sería si dos mensajes distintos tienen información repetida, como un substring. El atacante podría distinguir entre ambos ciphertexts que partes se repiten.

La gracia del cifrado simétrico es que dos mismos plaintext al cifrarse sean completamente distintos, y ECB no lo consigue.

Sobre PKCS5Padding se utiliza en cifrados de bloque con tamaño de 64bit así que al cifrar por AES usaras bloques de dicho tamaño. Si tienes alguna duda con ello preguntame, ya que conozco su implementación, aunque OpenSSL u otra librería ya lo implementará de serie al cifrar.

Saludos!

[openssl rand -base64 48 -out key.txt]

De nada hombre, aquí estamos para ayudar.

Una duda que tengo para generar la clave simétrica aleatoria de 128, yo estaba probando con openssl rand -base64 48 -out key.txt, pero no se si tiene sentido y verdaderamente éste comando me lo crea dicha clave con los 128 bits.

Ahí estás generando una clave aleatoria de 128 bits, pero sin seguir el estandar de generación de claves para cifrado simétrico, y tampoco sigues las directivas que OpenSSL recomienda en https://wiki.openssl.org/index.php/Enc . Existen clave simétricas no deseables para el cifrado, imagínate que por casualidades de la vida ese comando te generá una clave aleatoria no deseable para el cifrado Si guardas el Salt, podrás recuperar la clave en cualquier momento. Si cifras con la misma clave AES asegurate de generar un IV distinto. ¿Cómo se genera la clave y el IV? Pues a través de un salt + la password usando PBDKF2. En el link que te he dado arriba también verás que puedes guardarla en B64, y otras opciones que son muy útiles a la hora de trabajar con OpenSSL.

Saludos!

[pass]

Por lo que veo te dan una clave pública en formato .pem y tu debes generar una clave simétrica AES-128 bit para posteriormente cifrarla con dicha pública y enviarla. No veo que uses firmas digitales o mecanismos de integridad, lo cual en una aplicación real pone en peligro este mecanismo.

Comentas que es un proyecto, por lo tanto estarás usando uno o varios lenguajes de programación. En la mayoría de lenguajes existen librerías que te permiten hacer esto, pero yo te pondré un ejemplo con OpenSSL. Aunque en AES-CBC no se puede reutilizar el mismo IV dos veces.

Primero genera una clave AES-128 bit para cifrar en modo CBC:

Código [Seleccionar] Expandir

openssl enc -aes-256-cbc -k pass -P -md sha1

Obviamente donde pone pass pones una password, si quieres, aleatoria. El output del comando será la key+iv+salt. Guarda la key en un fichero llamado key.bin, ya que no has dicho nada de cifrar con AES, por lo tanto el IV y salt no nos sirven para este ejemplo.

Ahora cifra la clave AES-128 con la RSA que te han suministrado:

Código [Seleccionar] Expandir

openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in key.bin -out key.bin.enc

Donde id_rsa.pub.pem es la pública que te han suministrado, key.bin es la AES-128 que has generado y key.bin.enc es el fichero que se creará después de ejecutar el comando, con la AES-128 cifrada por la pública RSA.

Saludos!

Buenas matake, por lo que veo tienes un lío en esto:

Y dicha clave AES (la que utilizo para cifrar la privada mía) tendré que tenerla fuera del servidor ... sino no le veo lógica. ¿Es esto correcto?

Si es así ... entonces entiendo que la publica me basta para autenticación 100%,
pero en este caso (si no me equivoco) aunque este autentificado, el usuario no puede descifrar sus datos.

A no ser que no he entendido  bien el proceso

Tambien estoy un poco confundido cuando me dices de las privadas del servidor
¿Hablamos solo de la privada del user generada por servidor? o de dos privadas una del user y otra mia (ambas presentes en el servidor).

Quizá me haya explicado mal en ese sentido, espero que ese post sirva para aclarar todas tus dudas sobre el proceso de generación de claves en el sign-up y sobre el proceso de autenticación.

Primero antes de todo, el usuario y el servidor tienen dos pares RSA distintos, ambos de 2048-bit. La clave privada del servidor estará cifrada por una clave AES que tu has generado (sólo tu conoces). Esa clave es conveniente que esté en otro lugar distinto al servidor, o que para tener acceso se necesite de privilegios root. El par RSA del usuario lo debe general el mismo, no el servidor. Si sólo existiera el par de claves en el lado del server, el usuario no podría computar firmas digitales, por lo tanto cualquiera ha podido enviar información al server y tu no sabrías como autenticar dicha información.

Para cifrar los datos del usuario, la primera vez que el usuario hace sign-up (registro), se genera un par de claves para ese usuario, le obligas a introducir una passphrase que derivarás en una AES y cifrarás su privada con ella (todo esto del lado del usuario repito). Ahora se genera una AES aleatoria de lado del usuario, se computa una firma digital con la privada del usuario sobre sus datos, se cifran los datos por esa AES aleatoria y se cifra la AES aleatoria con la pública del server.

El usuario envía AES aleatoria cifrada por pública del servidor, datos cifrados por AES aleatoria y firma digital sobre los datos.

El servidor recibe dichos datos, descifra la AES con la privada del servidor, descifra los datos del usuario con la AES descifrada y verifica la firma digital sobre esos datos descifrados con la pública del usuario. La pública del usuario has de enviarla de alguna forma antes de este proceso. Si la firma digital es correcta entonces sabes que los datos del usuario no han sido modificados y que el usuario hizo la firma digital con su privada y nadie más pudo, así que autenticado al 100%.

Ahora guardas en la DB del server los datos cifrados por esa AES y guardas la clave AES asociada a esos datos cifrada por tu pública (la del server). Así si entran al server no podrán leer los datos de cada usuario, porque la clave AES que los descifra está cifrada por tu pública (sólo se puede descifrar por la privada tuya), y como tu privada está protegida con una AES que sólo tu conoces, pues, game over para el attacker.

¿Pero como descifra esos datos el usuario? Bueno, ese trabajo lo haces tú. Coges la info cifrada del usuario, la clave cifrada AES asociada a esa info y descifras con tu privada la AES asociada a esos datos y posteriormente los datos. Ahora los datos están en plano y se los puedes presentar al usuario. Si el usuario los modifica puedes obligarle a repetir el mismo proceso de generar AES aleatoria, firma digital sobre los nuevos datos etc, para que cada vez que cambien los datos se le asocie una nueva AES.

Ahora sólo queda el proceso de autenticación, que es lo mismo pero con un mensaje aleatorio.

Saludos!