secretas - Cómo almacenar información crítica, como secreto, clave, token, encryptionKey en la aplicación iOS
qué hacer si se me olvida la contraseña de una nota en apple (6)
Cuando hablamos de proteger la aplicación iOS, a menudo nos olvidamos de proteger la información más crítica, como secreto, clave, token, encryptionKey. Esta información se almacena en iOS binario. Así que ninguno de los protocolos de seguridad del lado de tu servidor te ayudarán.
Existe una gran cantidad de sugerencias de que no debemos almacenar dicha información en la aplicación, sino en el servidor y obtenerla a través de una llamada de servicio web segura SSL. Pero esto no es posible para todas las aplicaciones. Por ejemplo, si mi aplicación no necesita ningún servicio web.
En la aplicación iOS tenemos la siguiente opción para almacenar información.
- UserDefault : no apropiado para este caso
- Constante de cadena : No es apropiado para este caso. Puede ser de ingeniería inversa para recuperar o simplemente usar el comando de cadenas
- Base de datos segura : Almacenar en base de datos segura y encriptada. Pero nuevamente tenemos la responsabilidad de asegurar la base de datos de usuario y contraseña.
- Llavero : Mejor para almacenar información crítica. Pero no podemos guardar información antes de instalar la aplicación. Para almacenar en el llavero, primero necesitamos abrir la aplicación, leer de alguna fuente y guardar en el llavero. Tampoco es apropiado para nuestro caso.
- Constante de cadena de hash personalizada : para no usar directamente el secreto, el token, la clave del proveedor de servicios (mixpanel, paypal), en su lugar use la versión de hash de esa información de la clave personalizada. Esto tampoco es la solución perfecta. Pero agrega complejidad durante la piratería.
Por favor envíe alguna solución impresionante a este problema.
Estoy de acuerdo con @Lobsterman y creo que la mejor manera será usar una combinación de estos.
- No incluya la información secreta en la aplicación inicialmente.
- Entregar la clave secreta ya sea como contenido de compra en la aplicación, como recurso a pedido o enviarlo a través de notificaciones push. Esto agregará el beneficio de cambiar la clave periódicamente si lo desea y el cambio entrará en vigencia sin ningún esfuerzo adicional.
- Agregue la entrada al acceso de llavero una vez que se entregue el contenido.
Me parece que la mejor manera de hacerlo es utilizando el CloudKit integrado . Puede guardar sus secretos en el Panel de CloudKit y luego recuperarlos en el inicio. Dado que CloudKit es solo una capa de transporte, tendrás que almacenar los secretos de la aplicación en el KeyChain.
Sé que mencionó que el KeyChain no es ideal para su caso de uso (no estoy seguro de por qué), pero esta es una buena manera de no incluir los secretos en su aplicación. No puedes moverte a buscar los secretos de tu aplicación desde otra fuente.
El acceso a CloudKit se asegura utilizando la cuenta de iCloud del sistema y, si no hay una cuenta de iCloud, aún se puede acceder a los servidores de iCloud de forma segura. Otro beneficio adicional de esto es que puede cambiar los secretos de su aplicación en cualquier momento, por lo que si desea estar aún más seguro, puede implementar un programa de rotación.
Si los datos son extremadamente confidenciales, nunca se deben almacenar fuera de línea en el dispositivo porque todos los dispositivos son crackeables. Si aún desea almacenar en el dispositivo, entonces keychain es una opción para almacenar datos de forma segura. Sin embargo, el cifrado se basa en el código pin del dispositivo. Los usuarios no están obligados a establecer un pin, por lo que en algunas situaciones los datos ni siquiera se pueden cifrar. Además, el código pin de los usuarios puede ser fácilmente pirateado.
Una mejor solución es usar algo como SQLCipher que es una base de datos SQLite totalmente encriptada. La clave de cifrado puede ser aplicada por la aplicación y separada del código pin del usuario.
Si no quieres usar tu propio backend, usa Apple. Puede configurar los recursos a pedido y mantener el archivo de datos con su clave, token, cualquier secreto en el servidor Apple. Después de la primera descarga, puede escribir estos datos en el llavero, que es lo suficientemente seguro. Supongo que las redes entre iOS y el servidor de Apple también son lo suficientemente seguras.
Cocoapods-keys podría ser una mejor opción.
Desde cocoapods-keys doc''s
Los nombres de clave se almacenan en ~ / .cocoapods / keys / y los valores de clave en el llavero de OS X. Cuando ejecuta la instalación de pod o la actualización de pod, se crea una clase de Objective-C con versiones codificadas de las claves, lo que dificulta simplemente volcar el contenido del binario descifrado y extraer las claves. En el tiempo de ejecución, las claves se pueden codificar para usar en su aplicación.
Las clases generadas de Objective-C se almacenan en el directorio Pods / CocoaPodsKeys, así que si está revisando su carpeta Pods, simplemente agregue Pods / CocoaPodsKeys a su archivo .gitignore. CocoaPods-Keys admite la integración en proyectos Swift o Objective-C.
Consulte este enlace para ver la instalación, el uso y más información: https://github.com/orta/cocoapods-keys
1) Se requiere conexión a Internet
1.1) Notificaciones push La mejor manera de tener un intercambio de datos seguro es utilizar los servicios push (silenciosos) de Apple, aquellos que usan los apns y envían datos a través de https - más detalles 3.1
1.2) Un enfoque más o menos similar también se usa cuando se distribuyen nuevos certificados de usuario a aplicaciones ya implementadas, si una reinstalación de la aplicación no es una oportunidad Y la aplicación requiere una conexión a Internet que funcione de todos modos.
Desventaja: se requiere una conexión de red en funcionamiento y, básicamente, la información llega a la aplicación, cuando ya se está ejecutando => no parece ser adecuada para su caso. (ver paso 4)
2) Datos estáticos (ya que no habrá intercambio sin conexión de red / interlocutor de comunicación)
El cifrado de datos con clave privada se proporciona en el propio paquete. Ya sea que se trate de una cadena o un hash, que puede diseñarse mediante ingeniería inversa con las funciones que tiene incorporadas en su aplicación. Desde iOS9 es bastante difícil descompilar las aplicaciones de iOS y, básicamente, verás principalmente los archivos de encabezado provistos. Entonces, si tuvieras una función, cadena, valor hash o lo que sea, ¡asegúrate de tenerla en tu archivo .m!
Pero nuevamente: si la información no es específica del dispositivo o del usuario, solo es un secreto en su microentorno, válida en todos los dispositivos, tendría que proporcionar los datos cifrados Y el método de descifrado en el mismo paquete, si no hay un proceso de actualización / Intercambio de información o alguna otra cosa, se te ocurre.
Bueno para el cifrado: iOS System.Security https://developer.apple.com/reference/security o simplemente openssl
La diferencia entre su enfoque de llavero descrito es: usted tiene un valor, que se cifrará y almacenará de forma segura. (2) describe el enfoque para tener un valor semi seguro encriptado y almacenado (en paquete), que SE descifrará
3) Intercambio de información
Describes datos críticos, que fueron hasheados por otra instancia. ¡Genial! - Asegúrese de que, realmente, la instancia con la que está hablando es realmente la instancia que espera que sea (Prevención de enganche de red con identificación de certificado ssl, etc., pero incluso aquí puede haber intrusos (hombres en el medio)). Y (probablemente) tendrá un certificado que se proporcionará en su paquete de aplicaciones, para garantizar la autenticidad del servidor de comunicaciones; aquí va de nuevo, los datos que deben garantizar un proceso seguro entre ciertas instancias de su entorno micro. Sin embargo, estos datos se proporcionan en el paquete de su aplicación.
3.1 Intercambio seguro de información extendido - Silent Push Haga uso de los servidores de Apple para intercambiar sus secretos para este propósito. Si solo necesitas intercambiar pequeños trozos de datos. Recomendaría usar notificaciones push silenciosas para el usuario, incluso funcionan sin el permiso explícito del usuario. Gran ventaja: en caso de que cambien sus secretos o claves, puede informar a los usuarios lo antes posible sobre el cambio. Es probable que solo necesiten el cambio cuando reciban nuevos datos, que deberían funcionar de manera confiable en la mayoría de los casos. Excepción: el intercambio de datos en redes locales o mediante bluetooth, en este caso recomendaría enviar una notificación al usuario para que actualice la clave de descifrado local. O intercambiar la clave en este formato también. Una vez más: estoy filtrando información detallada sobre la arquitectura de su entorno. Desventaja: no sabe si un usuario acaba de usar su aplicación por primera vez, hasta que el usuario "le diga". https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1
3.1 Intercambio seguro de información extendido - Compra en la aplicación Use una compra gratuita dentro de la aplicación para que el usuario obtenga los datos en su teléfono. Buen punto aquí: puede proporcionar grandes porciones de datos fácilmente, ya que esta debe ser una solicitud activa del usuario, el usuario espera cierto tiempo de procesamiento y también debe ser consciente del hecho de que requiere una conexión a Internet que funcione. Desventaja: El usuario tendría que seleccionar esto a propósito. Hasta entonces la aplicación no funcionaría de forma acorde. https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction.html#//apple_ref/doc/uid/TP40008267
Por lo tanto, difiere ligeramente del enfoque (2) en su idea básica.
En resumen: ¿puede proporcionar información adicional, qué tipo de datos necesita cifrar / desea almacenar de forma segura y si tendrá un intercambio de red o no?
Necesitaría más información aquí :-)
Me gustaría enfatizar una vez más que una aplicación en iOS ya no es tan fácil de descifrar, incluso la descompilación no obtendría todo, se espera que lo consiga. Por ejemplo, las herramientas de descifrado como dumpdecrypt solo funcionaban correctamente hasta iOS 8.4