queremos utilizar certificados en el iPhone para autenticarse para MS Exchange Sync. No estamos seguros de cómo se implementa el concepto de seguridad para proteger estos certificados.iOS Keychain Security
p. Ej. ¿Es posible obtener el acceso de llavero "completo" en el iPhone si no está habilitado ScreenLock? (o con un iPhone con Jailbreak).
¿Alguien tiene algunos enlaces sobre esto?
Respondo parte de su pregunta, pero como la otra parte aún se desconoce, votaré la pregunta ya que también estoy ansioso por saber la respuesta.
La parte que puedo responder es: '¿puede una aplicación obtener acceso completo a un llavero si no está habilitado el bloqueo de pantalla'? No, cada aplicación tiene su propia área de llavero en el iphone, lo que significa que una aplicación solo puede acceder a sus propios secretos. Estos secretos no están bloqueados para la aplicación en sí misma, por lo que no hay forma de ocultar las entradas de la llave de la aplicación en sí. Para resumir: una aplicación puede leer sus propias entradas y ninguna otra entrada.
Lo que me interesa saber es qué sucede con los dispositivos con jailbreak. ¿Están los llaveros de todas las aplicaciones expuestas una vez que un dispositivo tiene un jailbreak?
Normalmente, el llavero sería la forma recomendada de almacenar dicho certificado. Sin embargo, se ha descubierto que jailbreaking se puede utilizar para eludir la seguridad del llavero (article).
Según tengo entendido, solo se puede acceder a elementos de llavero con clases de protección específicas con la técnica descrita. Estas clases son 'kSecAttrAccessibleAlways' y' kSecAttrAccessibleAlwaysThisDeviceOnly'. Consulte http://forum.agile.ws/index.php?/topic/2003-security-question-ios-keychain/page__view__findpost__p__20369 para obtener más detalles. –
Sí, ese artículo simplemente confirma que no debe almacenar elementos sensibles con el atributo kSecAttrAccessibleAlways, consulte http://developer.apple.com/library/ios/#DOCUMENTATION/Security/Reference/keychainservices/Reference/reference.html – gheese
Franhofer hizo un estudio sobre la seguridad del llavero de iPhone:
http://www.sit.fraunhofer.de/Images/sc_iPhone%20Passwords_tcm501-80443.pdf
estudio de Fraunhofer en la seguridad llavero iOS:
Por lo que puedo decir, hay dos niveles de encriptación que usa el llavero iOS. El primer nivel usa el código de acceso de la pantalla de bloqueo como clave de cifrado. El segundo nivel usa una clave generada y almacenada en el dispositivo.
Los investigadores de Fraunhofer han descubierto cómo moverse en el segundo nivel. Este es el nivel "más fácil" para moverse, ya que la clave de cifrado está almacenada en el dispositivo. Por lo tanto, en iOS4, su método solo funciona con las entradas de llavero que NO usan kSecAttrAccessibleWhenUnlocked o kSecAttrAccessibleWhenUnlockedThisDeviceOnly, porque esas entradas residen en la memoria con el primer nivel descifrado, incluso cuando el teléfono está bloqueado.
≈50ms por contraseña try; → ≈20 intentos por segundo; → ≈1.7 años para un 50% cambio de adivinar el código correcto para un código alfanumérico de 6 dígitos con base 36. El código simple estándar de 4 dígitos numéricos sería forzado en menos de 9 minutos. Basado en el supuesto de que el contador de intentos incorrectos en el IOS se puede omitir, ya que no es
Apple Inc. WWDC 2010 basada en hardware, Core OS, Sesión 209 "Protección de Datos", corredera 24
Resultado final: Si debe almacenar datos confidenciales, utilice mejor su propio cifrado. Y no almacene la clave en el dispositivo.
Editar: Hay numerosos news articles la que citar el estudio del Instituto Fraunhofer y tranquilizar a sus lectores que no se preocupe menos que se roban sus dispositivos, ya que este ataque sólo se puede hacer con el acceso físico al dispositivo.
Estoy de alguna manera dudoso. El hecho de que los investigadores hicieron sus pruebas con el acceso físico al teléfono parece haber sido solo una forma de simplificar el problema, en lugar de ser una limitación. Esta es la descripción de lo que hicieron para descifrar las entradas Llavero:
Después de usar una herramienta de jailbreak, para obtener acceso a una consola de comandos, que ejecutar un pequeño script para acceder y descifrar las contraseñas que se encuentran en la llavero. El descifrado se realiza con la ayuda de las funciones proporcionadas por el sistema operativo .
Como cualquiera que haya utilizado jailbreak.me sabe, jailbreaking no requiere física acceso al dispositivo. En teoría debería ser trivial para modificar el código jailbreak.me y lo han automatizar los siguientes:
Así, una vez más, tenga cuidado con lo que pone en el llavero.
Acceso físico a el dispositivo es necesario, porque hay una clave almacenada en algún lugar de la placa base a la que no se puede acceder ni leer por ningún medio. Esta clave es única para cada dispositivo iOS fabricado, y significa que * solo ese dispositivo específico * es capaz de descifrar los datos del dispositivo. Por lo tanto, se requiere acceso físico para descifrar, porque tienes que instruir al dispositivo para que se descifre. Descifrar el dispositivo de otra forma es prácticamente imposible (como en el ataque de fuerza bruta que lleva miles de millones de años). Esto no se aplica a las copias de seguridad, que se cifran sin la clave en el dispositivo –
@AbhiBeckert: Creo que entendiste mal el significado del acceso físico. El artículo de noticias vinculado dice _ "El ataque, que requiere la posesión del teléfono ..." _. Pero, de hecho, no hay ninguna razón por la cual un exploit ** remoto que se ejecuta en el dispositivo ** no pueda hacer lo mismo. – pepsi
Un exploit de código remoto (improbable en un teléfono completamente parcheado) todavía corre con los mismos permisos que la aplicación explotada, y todas las aplicaciones se ejecutan en un entorno limitado, sin acceso de lectura a archivos fuera de un solo directorio creado específicamente por el sistema operativo (vacío por defecto). Para que un exploit de código remoto pueda obtener acceso arbitrario al sistema de archivos, se requerirá un usuario que haya rooteado su teléfono (el punto de enrutamiento completo) o un exploit de escalada de privilegios. Una vez más, si aplica parches, estará bastante seguro. Dos exploits de día cero es un tramo. Sin la ruptura de la cárcel, solo el USB permite el acceso completo al sistema de archivos. –
Esta pregunta sería apropiada en http://security.stackexchange.com –
Aún así, muy relevante para todos nosotros desarrolladores de iOS que frecuentan Stack Overflow. Quizás todos deberíamos visitar security.stackexchange.com con más frecuencia? :) –