Si pongo datos cifrados en datos centrales en iOS o macOS, ¿cómo podría un hacker descifrarlos?

2

Supongamos que hice una aplicación que le permite a un usuario ingresar texto sin formato y cifrarlo con una contraseña. Luego, la aplicación almacena el texto cifrado en los datos básicos. El usuario puede seleccionar un "archivo", ingresar la misma contraseña para descifrarlo, y luego ver el texto simple (pero con suerte no el texto cifrado). Si se ingresa una contraseña incorrecta, la aplicación no intentará descifrar el texto cifrado.

  1. ¿Cómo podría uno adquirir y ver el texto cifrado? ¿Es posible? Espero que esto sea de gran ayuda para quienes intentan descubrir el algoritmo o descifrar el texto cifrado.
  2. ¿Cómo se podría alterar el texto cifrado para que pudieran intentar descifrarlo y aprender más sobre el algoritmo? ¿Es posible alterar los datos centrales de una aplicación sin usar las funciones de actualización integradas de las aplicaciones?

Suponga que ni la contraseña, el texto sin formato ni el texto cifrado se envían a través de una red.

Espero que debo proporcionar más detalles. Solo házmelo saber.

    
pregunta twharmon 10.01.2017 - 15:35
fuente

3 respuestas

1

La criptografía se puede usar para proteger contra la manipulación incluso con ataques sin conexión . La criptografía moderna que no detecta la manipulación y se basa en el secreto de sus algoritmos debe considerarse roto y es esencialmente inútil. Un criptosistema moderno (por ejemplo, AES-GCM) utiliza algoritmos completamente públicos, es resistente al criptoanálisis diferencial y a prueba de manipulaciones con acceso sin conexión al texto cifrado.

    
respondido por el flakeshake 12.04.2017 - 13:24
fuente
-1

Descargo de responsabilidad: como no conozco bien la arquitectura de Apple, no responderé la pregunta "cómo podría", solo la pregunta "podría alguien" y agregaré algunas ideas sobre cómo debería crear una aplicación que use cifrado.

Se encuentra en enlace :

Core Data makes no guarantees regarding the security of persistent 
stores from untrusted sources and cannot detect whether files have been
maliciously modified. The SQLite store offers slightly better security than
the XML and binary stores, but it should not be considered inherently 
secure. Note that you should also consider the security of store 
metadata since it is possible for data archived in the metadata to be 
tampered with independently of the store data. If you want to ensure 
data security, you should use a technology such as an encrypted disk image.

Básicamente, no puedes (y no debes) confiar en que los datos centrales están seguros.

Eso significa que debes esperar que alguien pueda modificar y acceder a tu texto cifrado.

Además, si no confías en que nadie descubra tu algoritmo (seguridad a través de la oscuridad) para asegurar algo, tendrás un mal momento.

Finalmente, sugeriría usar un método probado y verdadero:

  • el usuario ingresa una contraseña
  • toma la suma de comprobación sha 256 de [contraseña + algún número pseudoaleatorio (llamado sal)]
  • usa esto como tu clave
  • (de / en) crypt el texto con AES, usando la clave que generó.

Convenientemente, sha256 nos da 256 bits, y AES necesita una clave de 128, 192 o 256 bits.

La sal debe ser algo que pueda calcularse fácilmente, como otro hash de la contraseña o que se almacena junto con el archivo. (hace que sea un poco más molesto para la fuerza bruta)

Voila, sus datos están protegidos, la única * manera de descifrarlos es descifrar AES (probablemente no en el futuro) o saber / forzar la contraseña.

Una forma de reducir la fuerza bruta es usar un pimiento, un pequeño número generado aleatoriamente cada vez que el usuario usa su contraseña, se agrega a la sal.

La forma en que funciona es que usted prueba todos los pimientos hasta que encuentre el que abre el archivo, que es "lento" (si tiene 16 pimientos posibles, lo hace en promedio 8 veces antes de abrir el archivo, pero con la contraseña equivocada, intente con los 16 antes de descifrar) pero lo suficientemente rápido para que el usuario no se dé cuenta, con algo así como un tamaño de pimienta de 8 bits (0-255) puede tardar 1 / 10s, que es realmente doloroso para un ataque de fuerza bruta en la contraseña, pero no es realmente lento para el usuario.

para reducir la velocidad nuevamente, puedes usar varias rondas del algoritmo hash que elegiste. p.ej. hash (hash (hash (contraseña + sal)))

No estoy seguro de si es importante en este caso, pero solo para estar seguro de usar sha256 en lugar de md5.

En lugar de rodar su propia versión de una función de derivación de clave concatenando un salt con la contraseña y aplicando el hash varias veces, use uno ya hecho como PBKDF2. para hacer eso, use PBKDF (contraseña, sal, número de iteraciones), cuanto mayor sea el tamaño y la entropía de la sal, y cuanto mayor sea el número de iteraciones, mejor.

    
respondido por el satibel 11.01.2017 - 14:34
fuente
-1

Sólo se puede confiar en el cifrado que usted controla completamente. Cualquier cosa 'almacenada' en la computadora está en peligro, por lo que el método lógico es usar un cifrado que no esté conectado a Internet. Los instrumentos de cifrado de la vieja escuela ahora están regresando debido al hecho de que los comunicadores controlan cada aspecto del proceso.

El Galaxy Cipher Instrument es un ejemplo: Cryptography Forums, Topix.

Los patrones también deben ser patrones no lógicos, como la forma de un cable que se encuentra en un depósito de chatarra, la línea de torsión de un río en un mapa, cualquier cosa.

Hay un punto en cada disco en algún lugar entre los números que se usa como referencia para cambiar el siguiente disco. Este instrumento es seguro incluso de la NSA.

    
respondido por el Russell Lee 02.06.2017 - 17:01
fuente

Lea otras preguntas en las etiquetas